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Zusammenfassung 

Auf Basis einer Darstellung von annotationsbasierten Agenten in Kapitel [T] beschreibt Ka- 
pitel [2] Werkzeuge und eine formale Notation zur Definition und Durchfiihrung von Expe- 
rimenten im Text-Mining, in Form einer statisch typisierten, eingebetteten DSL. Am Bei- 
spiel von maschinellem Lernen zur Klassifikation zeigt Kapitel [3j wie mit diesem Framework 
Text-Mining-Experimente entwickelt und automatisch dokumentiert werden konnen. Kapitel 
[4]stellt zusammenfassend dar, wie das Konzept der generischen, typsicheren Annotation dabei 
zur Modellierung von Prozessen der Informationsverarbeitung genutzt werden kann, und in- 
wiefern es einem allgemeinen Informationsmodell entspricht, das iiber die Textprozessierung 
hinausgeht. 
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1. Text-Mining mit annotationsbasierten Agenten 



Die standig zunehmende Menge digital verfiigbarer Daten erschwert zunehmend das Auffinden 
gesuchter Informationen. Text-Mining, die Analyse von unstrukturierten textuellen Daten, ver- 
spricht hier eine Verbesserung, etwa durch die Ermoglichung intelligenter Suche in Form eines 
semantischen Information-Retrieval. Es fehlt aber an Methoden und Werkzeugen zur Erstellung 
von modularen Verfahren, die mittel- oder langfristig Text-Mining auf menschlichem Niveau er- 
moglichen. Bestehende computerlinguistische Werkzeuge fiir komponentenbasiertes Text-Mining 
erfordern einen Mehraufwand bei Implementierung und Dokumentation gegeniiber isolierten L6- 
sungen und werden deshalb bisher wenig genutzt. 

Ziel dieser Untersuchung ist daher die Entwicklung von Konzepten und Werkzeugen, welche 
die computerlinguistische Arbeit durch eine moglichst weitgehende Unterstiitzung bei der Model- 
lierung, Dokumentation und Evaluierung zugleich erleichtern und verbessern. Um sowohl com- 
puterlinguistisch fundiert als auch fiir neue Bereiche ausbaufahig zu sein, werden die Werkzeuge 
auf Basis einer Verbindung von Konzepten aus Computerlinguistik und allgemeiner Kunstlicher 
Intelligenz beschrieben und entwickelt, namlich als annotationsbasierte Multiagentensysteme. Die 
Werkzeuge sollen soweit wie moglich mit bestehenden Softwarekomponenten integriert werden, um 
eine moglichst hohe praktische Nutzlichkeit zu erreichen. Sie werden dabei von einfachen Beispie- 
len ausgehend entwickelt und fiir komplexe Beispiele aus der lexikalischen Semantik ausgebaut, 
die verschiedene Verfahren des maschinellen Lernens zur Klassifikation einsetzen. Hierbei soil sich 
zeigen, inwiefern die moglichst einfachen Konzepte und Werkzeuge sowohl fiir grundlegende wie 
fiir komplexe Aufgaben eingesetzt werden konnen. 

1.1. Text-Mining und Modularitat 

1.1.1. Computerlinguistische Komponentensysteme 



Dieser Abschnitt ( 1.1.1 ) gibt basierend auf eigenen Vorarbeiten (Steeg 2007) einen kurzen Uberblick 
iiber komponentenbasierte Softwareentwicklung und computerlinguistische Komponentensysteme, 
der in den folgenden Abschnitten um eine Beschreibung der Rolle der Dokumentation (1.1.2 S.[2]) 



und eine Betrachtung der Urspiinge solcher Systeme (1.1.3 S. [3]) erganzt wird. 



Komponenten in der Softwareentwicklung Komponentenbasierte Softwareentwicklung ist ei- 
ne Weiterentwicklung der objektorientierten Softwareentwicklung mit dem Ziel einer verbesserten 
Wiederverwertbarkeit groBerer Softwarebausteine und einer daraus resultierenden Fokussierung auf 
die Geschaftslogik der zu erstellenden Anwendung anstelle der dazu notigen Infrastruktur (Gruhn 
& Thiel 2000:1). Eine Komponente ist ein gekapseltes Stuck Software, das eine bestimmte Funktio- 
nalitat, welche auch als Service bezeichnet wird, anbietet. Die Anforderungen an eine Komponente 
werden durch das Komponentenmodell defmiert, in dem die Komponente verwendet werden soil 
(Gruhn & Thiel 2000:15-6). 



Komponentensysteme in der Computerlinguistik Verfahren zur maschinellen Sprachverarbei- 
tung werden heute z.T. nicht mehr nur isoliert, sondern integriert entwickelt, in einer Software 
Architecture for Language Engineering (SALE), einer Infrastruktur fiir die maschinelle Sprach- 
verarbeitung. Eine solche Infrastruktur besteht aus Frameworks, Referenzarchitekturen und einer 
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Entwicklungsumgebung und bildet damit eine Art Werkzeugkasten fur die computerlinguistische 
Arbeit (s. Kohler 2005; Cunningham & Bontcheva 2006, und Ziegler 2007). Im Sinne der oben 
skizzierten Konzepte komponentenbasierter Entwicklung defmiert eine SALE so unter anderem 
das Komponentenmodell, mit dem die sprachverarbeitenden Komponenten verwendet werden sol- 
len. 

Bekannte SALEs sind etwa GATE 1 , LingPipe 2 , UIMA 3 oder SMILA 4 . Die Ausgangsfragen die- 
ser Untersuchung basieren auf eigenen Erfahrungen (Steeg 2007) bei der Entwicklung und Anwen- 
dung von Tesla (Text Engineering Software Laboratory) 5 , einer an der Abteilung fur Sprachliche 
Informationsverarbeitung der Universitat zu Koln entwickelten SALE, die konsequent dynamische 
Annotation (s. Benden & Hermes 2004; Hermes & Benden 2005) einsetzt. 

Die Implementierung von Text- Mining- Verfahren in einer SALE ermoglicht eine Integration der 
einzelnen Komponenten (z.B. Parsing, POS-Tagging, Disambiguierung, etc.) mit ihrer Anwendung 
(z.B. Informationsextraktion, maschinelle Ubersetzung, etc.). Der Einsatz einer SALE verbessert 
zudem Modularitat und Wiederverwertbarkeit, sowohl fachlich durch dynamische Annotation, bei 
der die urspriinglichen Daten stets verfiigbar bleiben (vgl. Hermes & Benden 2005 und Abschnitt 
1.2.1 S. [5]) als auch technisch durch dynamische Konfiguration (Hunt & Thomas 2003:135) von 



wiederverwertbaren Komponenten. 



1.1.2. Dokumentation, Nachvollziehbarkeit und Modularitat 

Das Ziel von computerlinguistischen Komponentensystemen ist zum Einen eine Vereinfachung von 
gewohnten Arbeitsablaufen - etwa die Entwicklung eines Parsers - und zum Anderen die Ermog- 
lichung neuer Tatigkeiten, etwa die Erstellung von komplexen Workflows (vgl. Bird & Liberman 
2000) - etwa die Integration des Parsers in einen Anwendungsfall zur maschinellen Ubersetzung. 
Diese zwei Ziele sind aber nicht ohne Weiteres miteinander in Einklang zu bringen: In der Praxis 
ermoglichen gangige Systeme eher neue Dinge als dass sie gewohnte Arbeitsablaufe erleichtern - sie 
verkomplizieren diese eher durch die notige Einarbeitung in die Frameworks. Dies ist vermutlich 
ein Grund, weshalb keine Losung bisher so weitgehende Akzeptanz gefunden hat, dass eine An- 
wendung solcher Systeme allgemeine Praxis ware. Der Mangel an Werkzeugen fiir die Entwicklung 
von nachvollziehbaren Softwarexperimenten im Text-Mining tragt damit auch zu dem generellen 
Problem bei, dass die Veroffentlichung von forschungsrelevanter Software entgegen offensichtlich 
scheinender methodischer Grundsatze der Wissenschaft nicht die Regel ist 6 . 



Dokumentation als Bedingung fiir Wiederverwendung Ein zentrales Problem komplexer Soft- 
waresysteme ist die Dokumentation. Gute Dokumentation ist eine Voraussetzung fiir wirklich mo- 
dulare Software, denn nur sehr gut dokumentierte Komponenten werden wiederverwendet, da kein 



1 General Architecture for Text Engineering, http : //gate . ac . uk/ 

2 LingPipe, http://alias-i.com/lingpipe/ 

3 Unstructured Information Management Architecture, http://uima.apache.org/ 

4 Semantic Information Logistics Architecture, http://www.eclipse.org/smila/ 

5 Tesla, http: //www. spinfo.phil-fak.uni-koeln.de/spinfo-forschung-tesla.html 

6 Zur grundlegenden Debatte um Empirie in der Computer linguistik vgl. Pedersen (2008), zur medialen Dis- 
kussion siehe etwa // you're going to do good science, release the computer code too, The Guardian, 5. 
2. 2010, http : //www. guardian. co . uk/technology/2010/f eb/05/science- climate- emails- code-release 
und Computational science: ...Error - . . . why scientific programming does not compute, Nature News, 13. 10. 
2010, http : //www. nature . com/news/2010/101013/f ull/467775a.html 
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Programmierer gerne schlecht (oder gar nicht) dokumentierte Software analysiert und integriert, 
selbst wenn sie gut entworfen ist. So zitiert etwa Brooks (Brooks 1975, Brooks 1995:224) David 
Parnas: 

"Reuse is something that is far easier to say than to do. Doing it requires both good 
design and very good documentation. Even when we see good design, which ist still 
infrequently we won't see the components reused without good documentation." 

Das Grundproblem von Softwaredokumentation Das Grundproblem der Softwaredokumenta- 
tion ist die Trennung von Quelltext und Dokumentation (etwa in Form von Word-Dokumenten, 
PDF-Dateien, Websites, Wikis etc.). Da Code und Dokumentation laufend synchronisiert wer- 
den miissen, fuhrt diese Trennung zu standig veralteter Dokumentation (Brooks 1995:169). Trotz 
vorhandener Ansatze, vor allem iiber Dokumentationsgeneratoren (wie Javadoc, Doxygen oder 
DocBook), ist diese Trennung ein zwar lange erkanntes (Brooks 1975; Knuth 1992) aber im We- 
sentlichen ungelostes Problem der Softwaretechnik. Werkzeuge spielen fur die Losung dieses Pro- 
blems eine wichtige Rolle, denn ohne Werkzeugunterstuzung setzten sich neuartige Konzepte nicht 
weitflachig durch. So beschreibt etwa schon Brooks (1975, 1995:165f.) die Notwendigkeit von Unit- 
Tests zur Programmdokumentation - ein Konzept das sich erst jetzt langsam durch Werkzeuge 
wie JUnit 7 durchsetzt. 

Die etablierte Form der Bewahrung und Weitergabe von wissenschaftlichen Erkenntnissen ist 
die schriftliche wissenschaftliche Arbeit. Entsprechend kann auch Software aufbereitet werden: als 
illustriertes, an einen menschlichen Leser gerichtetes Dokument (Knuth 1992, Brooks 1995:164). 
Eine solche Aufbereitung von Software nennt Knuth Literate Programming 8 . Softwarebasierte Er- 
kenntnisse sind nur dann vollstandig dokumentiert, wenn die Veroffentlichung die entwickelte und 
verwendete Software enthalt. In diesem Sinn kann Literate-Programming als eine Aufbereitung 
von Software fur nachvollziehbare wissenschaftliche Veroffentlichungen betrachtet werden. 

Es existieren Ansatze zur automatischen Dokumentation in bestimmten Domanen (z.B. Ahlich 
et al. 2008 fiir die Dokumentation von Modellen, vgl. neuere Entwicklungen wie das Mylyn-Intent- 
Projekt 9 ), doch es fehlt bisher - insbesondere fiir die computerlinguistische Arbeit - an modernen, 
integrierten Werkzeugen fiir automatische Dokumentation, Literate-Programming und vergleich- 
bare Ansatze. 

Eng verkniipft sind im Bereich des Text-Mining Dokumentation und Evaluation: Eine Inter- 
pretation von Ergebnissen erfordert eine vollstandige Dokumentation der verwendeten Verfahren 
und Daten. Es existieren Ansatze einer generischen, automatischen Evaluierung von computerlin- 
guistischen Verfahren (Bigert et al. 2003; Halpin 2006). Andere Ansatze sind meist fiir bestimmte 
Anwendungen spezialisiert, etwa fiir Textzusammenfassung (Lin 2004b. a) oder maschinelle Uber- 
setzung (Papineni et al. 2002; van Zaanen & Zwarts 2006). Die existierenden Ansatze sind meist 
nicht mit anderen Werkzeugen integriert - eine Ausnahme bildet hier das AnnotationDiff-Tool von 
Gate (Cunningham et al. 2002). 

1.1.3. Technische Urspriinge 



7 JUnit, http : //j unit . org 

8 Beispiele fiir literate programs finden sich z.B. unter http://en.literateprograms.org/ 

9 Mylyn Intent, http://wiki.eclipse.org/Intent 
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Entscheidungsdamonen 
Kognitive Damonen 
Berechnungsdamonen 
Datendamonen 

Abbildung 1: Struktur des Pandamoniums von Selfridge (1959) 

Blackboard-Architektur Die Blackboard- Architektur gilt als Ursprung von annotationsbasierten 
Systemen zur Sprachverarbeitung (Cunningham & Bontcheva 2006). Die Tafel (engl. Blackboard) 
ist eine alte Metapher der Softwareentwicklung: Newell (1962) beschrieb als Erster explizit die Tafel 
als gemeinsame Datenstruktur fiir den Datenaustausch zwischen Methoden. In diesem Sinn ist die 
Tafel eine Metapher fiir das Prinzip von explizitem Zustand, einem Konzept das ein zentraler (und 
durchaus problematischer) Aspekt von Programmiersprachen ist (vgl. Roy & Haridi 2004:405,569). 

Die Kriterien einer Blackboard-Architektur (vgl. Corkill 2003) umfassen: 1. mehrere kooperieren- 
de Quellen, 2. mehrere konkurrierende Hypothesen, 3. mehrere Abstraktionsebenen, 4. Feedback 
fiir die Quellen, 5. das Blackboard, ein assoziativer Speicher. Der Blackboard- Ansatz ist in verschie- 
denen Projekten angewendet worden, etwa im Hearsay-Spracherkennungsprojekt der 1970er Jahre 
(Erman et al. 1980) oder in der Cryptoanalyse. Hier sind die Quellen etwa Akustik, Phonetik, Ar- 
tikulation, Syntax, Semantik und Pragmatik (Hearsay) bzw. Haufigkeitsanalyse, Schlusselworter, 
Codebooks und Ubersetzer (Cryptoanalyse). Auf hoherer Abstraktionsebene kommen Blackboard- 
Architekturen auch fiir die Entwicklung komplexer Systeme in der Industrie zum Einsatz, oder fiir 
die Entwicklung von Open-Source-Software (wo alle Programmierer die Quellen sind). Diese sehr 
unterschiedlichen Beispiele machen deutlich, dass die Blackboard-Architektur ein natiirliches Prin- 
zip zur Losung komplexer Probleme darstellt. 

Pandamonium-Modell Newell (1962) nennt als Vorbild fiir seine Blackboard-Metapher das Pan- 
damonium-Modell von Selfridge (1959), eine Architektur fiir ein Mustererkennungssystem. Als 
solches ist das Pandamonium selbst viel naher am Thema der annotationsbasierten Sprachverar- 
beitung als die in diesem Zusammenhang haufig zitierte Blackboard-Architektur, die urspriinglich 
ein sehr allgemeines Konzept des Programmierens beschreibt (expliziten Zustand, s.o.). Das von 
Selfridge beschriebene Pandamonium besteht aus vier Ebenen von Damonen, die unter bestimmten 
Umstanden die Damonen der nachsthoheren Ebene informieren (s. Abb. [I]). 

Schon diese Darstellung der Mustererkennung bei Selfridge enthalt die zentralen Elemente des 
korpusbasierten, modularen maschinellen Lernens durch Klassifikation: die Datengrundlage, die 
Merkmalsberechnung auf den Daten, eine Verarbeitung der Merkmale, und eine Entscheidung iiber 
die Klassenzugehorigkeit. Bei der Verarbeitung im Pandamonium werden zunachst iiberwacht die 
Gewichte zwischen Berechnungsdamonen und kognitiven Damonen ermittelt. Unniitze Damonen 
werden elimiert und neue, zueinander in Konkurrenz stehende Damonen werden erzeugt. Eine 
solche Eliminierung unniitzer Damonen kann im maschinellen Lernen etwa als Merkmalsauswahl 
modelliert werden, bei der Merkmale eleminiert werden, die schlechte Ergebnisse liefern. Die Kon- 
kurrenz der Damonen entspricht auch einem zentralen Kernkonzept von Multiagentensystemen. 
Das Pandamonium bildet so die konzeptuelle Grundlage einer ganzen Reihe von Metaphern der 
modularen Softwarentwicklung, wie der dargestellten Blackboard-Architektur und Multiagenten- 



4 



systemen (s.u.), aber auch etwa dem Open-Spaces-Ansatz 10 oder Service-orientierten Architektu- 
ren. 



Die Agentenmetapher als gemeinsames Grundkonzept Ein etabliertes Konzept der Kiinst- 
lichen Intelligenz (KI) sind Agenten (Russell & Norvig 2003). Diese Agenten interagieren iiber 
Sensoren und Aktuatoren in Multiagentensystemen (Vlassis 2003; Lin 2007). Wenn auch bisher 
selten so formuliert (eine Ausnahme bildet hier etwa Yu et al. 2008), entsprechen sprachverarbei- 
tende Komponenten solchen Agenten, die in einer Welt aus annotierten Korpora agieren. 

Letztlich ist eine modulare Konzeption von Software der Grundgedanke aller Losungsansatze 
von strukurierter (Dijkstra 1968; Wirth 1971; Dahl et al. 1972) und objektorientierter Program- 
mierung, iiber das Konzept von Multiagentensystemen bis zu serviceorientierten Architekturen (wo 
Services die Schnittstellen der Module sind, vgl. Gruhn & Thiel 2000). All diese Konzepte sind un- 
terschiedliche Metaphern fur das Zusammenspiel der Einzelteile in Softwarekomponentensystemen 
(vgl. Corkill 2003). 

Der Kern des Konzepts der Multiagentensysteme, das mit dem Pandamonium und der Black- 
board- Architektur ubereinstimmt ist so die urspriingliche Bedeutung von Agent als 'der handelnde 
Teil, die wirksame Substanz, das Tuende'. Aus dem Zusammenspiel dieser wirksamen Substan- 
zen ergibt sich die Losung komplexer Probleme, hier etwa fur Aufgaben des Text-Mining. Eine 
Anwendung der allgemeinen Agentenmetapher im Bereich des Text-Mining verspricht dabei eine 
Generalisierung sprachspezifischer Konzepte. 



1.2. Modularitat durch Annotation 

Annotationen spielen eine zentrale Rolle in computerlinguistischen Softwaresystemen. Der Begriff 
der Annotation kann fur die Anreicherung von Daten mit Metadaten oder fur diese Metadaten 
selbst verwendet werden. Annotierte Texte dienen etwa als Input fur Suchwerkzeuge, fur linguis- 
tische Untersuchungen, oder zur Erzeugung neuer Annotationen. McEnery (2003:448) bezeichnet 
Annotationen als Treibstoff der maschinellen Sprachverarbeitung ("the raw fuel of NLP"), da sie es 
maschinellen Verfahren ermoglichen, die Intuition von menschlichen Experten, deren Analysergeb- 
nisse in Form von Annotationen festgehalten wurden, mithilfe maschinellen Lernens zu reprodu- 
zieren (s. Beispiele unten). Da auBerdem iiber den Vergleich von Annotationen (von verschiedenen 
Verfahren, Goldstandard, etc.) ermittelt werden kann, welches Verfahren die Expertenmeinung 
am treffendsten reproduziert, bilden Annotationen den konzeptionellen und technischen Kern des 
Text-Mining, gerade in Hinblick auf die beschriebenen Ziele modularer, optimierter Komponenten. 



1.2.1. Fachliche Urspriinge 

Dieser Abschnitt beschreibt die Grundlagen der Korpuslinguistik, basierend auf Darstellungen in 
eigenen Vorarbeiten (Steeg 2007). Im anschlieBenden Abschnitt 1.2.2, S.[7]wird darauf aufbauend 
die Entwicklung der Annotation als logische Zwischenschicht in Systemen zur maschinellen Sprach- 
verarbeitung beschrieben, einer zentralen theoretischen Grundlage der in den folgenden Kapiteln 
entwickelten Konzepte und Werkzeuge. 



10 Open-Spaces, vgl. Loosely Coupled Communication and Coordination in Next- Generation Java Middleware, 
http : / /today . java. net/pub/a/today/2005/06/03/loose .html 



5 



Korpuslinguistik Grundlegender fachlicher Ursprung des Annotationskonzepts ist die Korpuslin- 
guistik, deren Gegenstand die Erstellung und Auswertung von Textkorpora (Kohler 2005), sowie die 
Entwicklung von Werkzeugen fur die Erstellung und Auswertung von Textkorpora ist. Die Korpo- 
ra dienen dabei zur Beantwortung linguistischer Fragestellungen. Dementsprechend definiert etwa 
McEnery (2003) ein Textkorpus als grofie Menge linguistischer Evidenz. Eine solche, auf empiri- 
schen Daten basierende Linguistik kann als datengetrieben beschrieben werden. Dieser Ansatz ist 
wissenschaftstheoretisch fundiert, da echte Daten Annahmen des Linguisten stiitzen, aber auch 
widerlegen konnen (vgl. Labov 1975, 1996). Damit sind Korpora eine sehr wertvolle Quelle fur die 
linguistische Arbeit. Korpuslinguistische Methoden werden nicht nur in der maschinellen Sprach- 
verarbeitung angewendet, sondern auch in anderen sprachwissenschaftlichen Bereichen, etwa in der 
allgemeinen Sprachwissenschaft oder den Philologien, sowie auf verschiedenen Ebenen der Spra- 
che, etwa Morphologie, Syntax, Semantik oder Pragmatik (McEnery & Wilson 1996:2). Da ein 
grofier Teil der Auswertung von Korpora mithilfe von statistischen Verfahren erfolgt, wird diese 
Art der Arbeit mit Korpora auch als Quantitative Linguistik bezeichnet (s. Manning & Schiitze 
1999; Kohler 2005). 



Korpusannotation Annotierte Korpora sind Korpora, die mit verschiedenen linguistischen Infor- 
mationen angereichert wurden (McEnery & Wilson 1996:24). Bei diesen Informationen handelt es 
sich linguistisch betrachtet nicht um die Hinzufugung neuer Informationen, sondern um die Ex- 
plizitmachung bereits vorhandener linguistischer Struktur im Sprachmaterial (McEnery 2003:453). 
Ein Beispiel fiir Korpusannotation ist etwa die Kennzeichnung von Wortarten durch POS-Tags. An- 
dere Annotationen enthalten etwa Informationen iiber Stammformen (als Ergebnis einer Stamm- 
formenreduktion oder Lemmatisierung), iiber die syntaktische Struktur (solche Korpora werden 
auch Baumbanken genannt), sowie semantische, stilistische oder Informationen zur Diskursstruk- 
tur. Dabei sind morphologische Annotationen verbreiteter als syntaktische Annotationen und diese 
wiederum verbreiteter als semantische oder pragmatische Annotationen. Eine Anreicherung durch 
Annotation basiert immer auf einer bestimmten Interpretation der Daten. Beim Annotieren ist da- 
her zu beachten, dass der ursprungliche Text auch nach der Annotierung noch in seiner Rohform 
verfiigbar sein sollte, etwa durch dynamische Annotation (s. Benden & Hermes 2004, Hermes & 
Benden 2005, vgl. Abschnitt [i~2~2j S.Q. 

Uber die rein linguistische Arbeit hinaus ermoglichen annotierte Korpora es Computerprogram- 
men, die Intuitionen von Experten (die Autoren der Annotationen) in Bezug zu den annotierten 
Texten zu setzen und so menschliche Intuitionen zu reproduzieren. Grundgedanke ist hierbei, dass 
von Menschen annotierte Korpora vom Computer verarbeitet werden, wobei der Computer die 
Muster im Kontext der Annotationen lernt. Konkret konnte etwa gelernt werden, dass im Eng- 
lischen can als Nomen oft nach a oder the, als Verb dagegen nach to vorkommt (wenn zuvor 
Wortarten annotiert wurden). Ein Beispiel hierfiir sind etwa auf Hidden-Markov- Modellen (HMM) 
basierende POS-Tagger, die aus annotierten Korpora lernen und dadurch in die Lage versetzt 
werden, neue Texte zu annotieren (s. etwa Manning & Schiitze 1999). Daher bilden annotierte 
Korpora eine etablierte Grundlage fiir das maschinelle Lernen in der Sprachverarbeitung (McEne- 
ry 2003:459). 
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Abbildung 2: Input und Output einer Komponente im Text-Mining 



1.2.2. Dynamische Annotation als logische Applikationsschicht 

Wie oben dargestellt spielen annotierte Korpora sowohl fur die rein linguistische Arbeit wie fiir die 
maschinelle Sprachverarbeitung und damit fiir das Text-Mining eine herausragende Rolle. Aus die- 
sem Grund stellen Annotationen das konzeptuelle Austauschformat der Komponenten einer Text- 
Mining-Architektur (oder SALE) dar: Einzelne Komponenten bekommen als Input (in Agenten- 
Terminologie iiber ihre Sensoren) vorhandene Annotationen (und optional die Daten, d.h. den 
Text), und produzieren auf dieser Basis neue Annotationen (in Agenten-Terminologie mit ihren 
Aktuatoren). Abbildung [2] veranschaulicht dieses Prinzip. 

Die gangigen computerlinguistischen Komponentensysteme wie Gate oder UIMA basieren auf 
dem Annotationskonzept, das auf ATLAS (Architecture and Tools for Linguistic Analysis Systems, 
Bird & Liberman 2000) zuriickgeht. Dabei ist es aus verschiedenen Griinden (s.u.) vorteilhaft, den 
Text und die Annotation zu trennen (Stand-off markup oder dynamische Annotation, vgl. Benden 
& Hermes 2004). Die Annotation bildet so eine logische Ebene zwischen den Daten und den darauf 
operierenden Verfahren, und bildet so einen zentralen Teil der maschinellen Sprachverarbeitung. 



Urspriinge der physischen Trennung von Daten und Annotation Schon mit der aufkommen- 
den Verbreitung von Markup-Sprachen wie HTML und XML wurde erkannt, dass eine Trennung 
von ausgezeichneten Daten und Metadaten statt einer gemeinsamen Speicherung wie in ublichen 
Markup-Dokumenten fiir die computerlinguistische Praxis sinnvoll ist. So nennen etwa Thompson 
& McKelvie (1997) drei Griinde fiir eine solche Trennung: 1. Kopieren der Daten in ein Markup- 
Format ist nicht immer moglich, z.B. fiir schreibgeschiitztes Material oder zu grofie Datenmengen. 
2. Uberlappendes, hierarchisches Markup. 3. Rechtliche Probleme, z.B. kann der Text selbst ur- 
heberrechtlich geschiitzt sein, wahrend die Auszeichnungen weitergegeben werden sollen (vgl. zur 
rechtlichen Situation Hermes & Benden 2005). Dariiber hinaus sollte aus methodischen Griinden 
der Rohtext immer verfiigbar sein (vgl. Abschnitt 1.2.1 S.[6]). 



Ihren Ursprung hat diese Trennung von Daten und Annotation im EU-geforderten MULTEXT- 
Projekt, das den Schwerpunkt auf wiederverwertbare Korpora setzte, sowie im DARPA-Projekt 
TIPSTER (Harman 1992), in dessen zweiter Projekthalfte Softwarearchitekturen fiir standardi- 
sierte Textanalyse-Komponenten (und damit Text-Mining) im Mittelpunkt standen. Dies fiihrte 
dazu, dass bereits im Corpus Encoding Standard (CES) von 1996 eine Form von SGML-basiertem 
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Abbildung 3: ATLAS-Objektmodell aus Bird & Liberman 2000 



Standoff-Markup enthalten war. Diese erste Form stellte allerdings noch keine vollstandige Tren- 
nung von Daten und Annotation her: grundlgende Analysen wurden mit den Daten vermischt - 
so wurden Token in der Hauptdatei annotiert, und diese von anderen Dateien referenziert und mit 
Zusatzinformationen angereichert, vgl. Benden & Hermes 2004 zu den Problemen einer solchen 
unvollstandigen Trennung. 

Weiterentwicklung des Annotationskonzepts in ATLAS Eine entscheidende Weiterentwick- 
lung erfuhr das Annotationskonzept mit dem ATLAS-Projekt (Architecture and Tools for Lingui- 
stic Analysis Systems, vgl. Bird & Liberman 2000), das Vorbild fur spatere Entwicklungen wie 
Gate 2 (Cunningham et al. 2002) und UIMA wurde. Vor ATLAS bestanden sprachverarbeitende 
Programme konzeptuell aus zwei Ebenen: der Anwendung und der Datenhaltung. Dazwischen eta- 
blierte ATLAS als logische Ebene die Annotation 11 . Ziel einer solchen Schicht ist die Etablierung 
von flexiblen, erweiterbaren Werkzeugen und Frameworks durch die Entkoppelung der direkten 
Verbindung zwischen Daten und Algorithmen. Die Annotationsobjekte verweisen dabei auf Re- 
gionen in den Daten und enthalten die Metadaten (vgl. Struktur der Annotationsobjekte in Abb. 

Zum Speichern der Annotationen, und damit der Analyseergebnisse, gibt es verschiedene Stan- 
dards (wie TEI, CES, XCES, TUSNELDA oder Tiger), die von den verschiedenen SALE-Systemen 
als Exportformat unterstutzt werden und in diese importiert werden konnen. Intern werden meist 
eigene Formate verwendet. 

Als persistente Darstellung von Analyseergebnissen und als "information aqueduct" (Bird et al. 
2000) zwischen den Komponenten in "pipelined apps" (ebd.) bildet das Konzept der Annotation 
so den Kern von Text-Mining-Software. Da neben dieser logischen Schicht die Annotation eine 

11 In ersten Veroffentlichungen wird die logische Schicht in ATLAS als Annotationsgraph (annotation graph) mit 
beschrifteten Kanten beschrieben, spater vereinfacht zu einer Menge von Annotationen (annotation set). 
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wesentliche Rolle fiir die Evaluierung von sprachverarbeitenden Verfahren spielt, und annotierte 
Korpora die Datengrundlage linguistischer Untersuchungen bilden, kann die Annotation allgemein 
als das zentrale Konzept des Text-Mining betrachtet werden. 



2. Werkzeuge zur Modellierung im Text-Mining 



2.1. Werkzeuge zur Modellierung, Dokumentation und Evaluierung 

Die Modellierung der Multiagentensysteme soli moglichst unkompliziert erfolgen. Die Agenten- 
schnittstellen sollen als Teil der eigentlichen Funktionalitat, d.h. direkt im Code und nicht in einer 
separaten Konfigurationsdatei defmiert werden. Experimente sollen iiber eine einfache Fachsprache 
(domain-specific language, s. Abschnitt 2.2.2, S. 10) defmiert werden. Eine solche Modellierung 



von Experimenten iiber eine Fachsprache ermoglicht eine einfache Konfiguration der automati- 
schen Evaluierung und Dokumentation: Die verschiedenen zu evaluierenden Aufbauten werden in 
der Fachsprache modelliert und konnen so automatisch ausgefuhrt und aufbereitet werden (vgl. 



Abschnitt 2.3.6, S. 19). Die Dokumentation der Experimente soil die beteiligten Agenten, Visuali- 



sierungen ihrer Interaktionen, sowie tabellarische Aufbereitungen von Ergebnissen enthalten (vgl. 



Abschnitt 3.4.5, S. 42). Im Unterschied zum klassischen Literate-Programming soil mit den Werk- 



zeugen nicht die menschenlesbare Form editiert werden, sondern diese soil aus dem Code generiert 
werden (wie bei den Dokumentationsgeneratoren DocBook, Doxygen oder Javadoc). Ein Vorteil 
dieses Ansatzes ist, dass bestehender Code leicht integriert werden kann, da kein spezifisches, neues 
Format vorausgesetzt wird (wie bei bestehenden Literate-Programming-Losungen, z.B. noweb 12 ). 

Die im Folgenden beschriebenen Konzepte und Werkzeuge sollen die Entwicklung von modula- 
ren, optimierten und wohldokumentierten Text-Mining-Komponenten vereinfachen und so einen 
entscheidenden Teil zur Entwicklung von funktionierenden Text-Mining-Systemen beitragen 13 . Zur 
Evaluierung der in Kapitel [2] beschriebenen Werkzeuge werden diese in Kapitel [3] fiir die Umset- 
zung komplexer Text-Mining-Experimente eingesetzt. Eine zentrale Frage ist dabei, inwiefern die 
moglichst einfachen Konzepte und Werkzeuge sowohl fiir grundlegende wie auch fiir komplexe 
Anwendungen eingesetzt werden konnen. 



2.2. Basistechnologien 

Im Folgenden werden einige softwaretechnische Konzepte beschrieben, welche die Basis der Umset- 
zung der Werkzeuge bilden: statisch typisierte Programmiersprachen und Fachsprachen (domain- 
specific languages, DSLs). 



2.2.1. Statische Typisierung 

Schon im ATLAS-Objektmodell enthalt eine Annotation ein Type-Attribut (vgl. Abbildung[3j S. 

Dieses spezifiziert die Art der Annotation, z.B. Token, POS, Bedeutung, etc. Das Konzept der 
Typisierung geht zuriick auf die Aristotelische Kategorienlehre und entspricht generellen Prinzipien 

12 A Simple, Extensible Tool for Literate Programming, http://www.eecs.harvard.edu/nr/noweb/ 

13 Eine Sicht auf die angestrebten Werkzeuge ist die eines Testframeworks fiir computerlinguistische Komponenten, 
konzeptuell vergleichbar mit den xUnit-Frameworks fur testgetriebene Entwicklung (Beck 2003) von generellen 
Softwarekomponenten . 
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der Kognition, deren zentrales Grundkonzept die Kategorisierung ist (vgl. Hawkins 2004; Harnad 
2005). Die Typisierung der Annotation ist damit ein wesentlicher Aspekt der Organisation von 
Information beim Text-Mining. 

In der Softwaretechnik kann das Konzept der Typisierung nicht nur als zusatzliche Informa- 
tion verwendet werden (diese Daten sind eine Zahl, eine Zeichenkette, etc.), sondern zusatzlich 
zur Uberpriifung, ob die Daten nur in sinnvoller Weise verwendet werden (z.B. zur Vermeidung 
von mathematischen Operationen mit Zeichenketten) . In statisch typisierten Programmierspra- 
chen werden solche Kontrollen vom Compiler ausgefuhrt und verhindern so, dass Fehler erst zur 
Laufzeit auftreten. So fiihrt statische Typisierung zu robusteren Programmen mit weniger Feh- 
lern. In der Softwaretechnik hat sich diese tiberpriifung bewahrt und gilt als ein Grund fiir die 
industrielle Dominanz von Programmiersprachen wie C++, Java oder C#. Die Typisierung stellt 
zudem eine zusatzliche Dokumentation der Quelltexte dar, die laufend und automatisch vom Com- 
piler uberpriift wird. Dabei wird fiir einen eingeschrankten Bereich das grundlegende Problem der 
Synchronisation von Quelltext und Dokumentation gelost. 

Aufgrund der beschriebene Vorteile typisierter Sprachen und der Tatsache, dass Annotationen die 
Grundlage von Text-Mining- Software sind und typisiert beschrieben werden konnen (s. Abschnitt 
1.2 S.[5]) ist es sinnvoll, Text-Mining typsicher zu modellieren. Die entwickelten Werkzeuge stellen 



daher ein Framework zur typsicheren Modellierung im Text-Mining dar und werden im Folgenden 
abgekiirzt als TM2 (Typsichere Modellierung im Text-Mining) bezeichnet. 

2.2.2. Domain-specific languages: textuelles MDD 

Fachsprachen (domain-specific languages, DSL) sind formale Hochsprachen, die auf eine bestimm- 
te Anwendung spezialisiert sind und mit denen man nah am Problem programmiert (Hunt & 
Thomas 2003:53, Parr 2007:3). Sie bilden eine Form von domanenspezifischer textueller Model- 
lierung oder formaler Notation, etwa fiir spezifische Aufgaben oder fiir Fachbereiche mit eigenem 
Vokabular 14 . Beispiele fiir DSLs sind etwa die Datenbankabfragesprache SQL oder die Graphenbe- 
schreibungssprache DOT. Ziel von domanenspezifischen Sprachen ist allgemein die Ermoglichung 
einer Formalisierung, die den Problembereich einfach und elegant erf asst. So kann etwa ein Graph 
in DOT folgendermassen modelliert werden: 

digraph{ 

1- >2 

2- >3 
2->4 




Implementierung von DSLs Zur Implementierung von DSLs lassen sich zwei Ansatze unterschei- 
den: eigenstandige (oder externe) und eingebettete (oder interne) DSLs. Unter einer eigenstandigen 
DSL versteht man eine komplett neu entwickelte Sprache, fiir die in der Regel eine Grammatik 
in einer eigenen Grammatikbeschreibungssprache geschrieben wird. Aus dieser wird mit Mitteln 



14 vgl. eigene Vorarbcitcn in Steeg et al. (2008) zur Implementierung einer formalen Notation fiir Functional 
Grammar und Functional Discourse Grammar. 



10 



der modellgetriebenen Software-Entwicklung ein Parser generiert (z.B. mit ANTLR, vgl. Parr 
2007), der Quelltext in der durch die Grammatik beschriebenen Sprache verarbeiten kann. Aus 
der Grammatik konnen zudem Werkzeuge ffir die Sprache (z.B. Editoren) generiert werden (z.B. 
mit Xtext 15 ). Auf Basis der Objekte des Parse- Trees, der vom generierten Parser geliefert wird, 
kann dann Quelltext in der DSL verarbeitet werden. 

Unter einer eingebetteten DSL versteht man die Verwendung einer existierende Sprache, die so 
flexibel ist, dass sie fiir die speziellen Zwecke einer Domane angepasst werden kann. Friihestes 
Beispiel fiir eine flexible Sprache, die eine Definition neuer Konstrukte ermoglicht (und sich so fiir 
die Entwicklung eingebetteter DSLs eignet), ist Lisp. Eine weitere altere Sprache mit eingebetteten 
DSLs ist Prolog, deren DCG-Bibliothek eine DSL zur Beschreibung von Grammatiken ist, und so 
als eingebettete DSL zur Entwicklung eingebetteter DSLs gesehen werden kann. Eine heute sehr 
beliebte Sprache zur Entwicklung eingebetteter DSLs ist Ruby - eine Sprache, die durch das 
Framework Ruby on Rails (das stark auf DSL-Konzepten basiert) weite Verbreitung fand. Diese 
Urspriinge erklaren, warum eingebettete DSLs lange mit dynamisch typisierten Basissprachen (host 
languages) assoziiert wurden. Mit neueren Sprachen wie Scala bleiben eingebettete DSLs jedoch 
nicht auf den Bereich dynamisch typisierter Sprachen beschrankt (s.u.). 

Wahl der Implementierungssprachen Die eingesetzten Sprachen sollen verbreitet sein und Un- 
terstiitzung fiir weitgehende statische Typisierung in Form von parametrischer Polymorphie bieten. 
Diese ermoglicht, dass das Framework generische Elemente enthalt, deren konkreter Typ erst durch 
die Implementierungen festgelegt wird, die das Framework verwenden (s.u.). Darfiberhinaus soil 
die Moglichkeit fiir eine einfache Entwicklung von eingebetteten oder eigenstandigen DSLs fiir die 
Modellierung von Experimenten gegeben sein. 

Java ist eine moderne, weit verbreitete 16 , hochperformante 17 objektorientierte Programmier- 
sprache. Da Java zudem open-source unter der GPL2 zuganglich ist und die JVM zunehmend 
von weiteren Sprachen verwendet wird, ist zu erwarten, dass Java langfristig verfiigbar sein wird. 
Java verfiigt fiber parametrischen Polymorphismus (Java Generics) und umfangreiche eigene und 
externe Programmbibliotheken, auch zur Entwicklung von eigenstandigen DSLs, z.B. mit dem 
Xtext-Framework. 

Alternative, Java-kompatible JVM-Sprachen eignen sich zur Implementierung von eingebetteten 
DSLs, z.B. Scala 18 , Clojure (ein Lisp-Dialekt, dynamisch typisiert), und JRuby (eine Ruby-Imple- 
mentierung in Java, dynamisch typisiert). All dies macht Java, oder allgemeiner die JVM, zu einer 
optimalen Wahl ffir ein Framework, das langfristig die Entwicklung von Text-Mining- Anwendungen 
auf Basis typsicherer Modellierung praktisch vereinfachen soil. 

Eine Unterstfitzung ffir parametrische Polymorphie gibt es in Java seit der Einffihrung von Ja- 
va Generics in Version 1.5 der Sprache. Um die Vorteile der statischen Typisierung zu nutzen, 
wird daher bei der Umsetzung der Werkzeuge konsequent auf Generics gesetzt. Dabei ergibt sich 



15 Xtext Language Framework, http://www.eclipse.org/xtext 

16 Im Tiobe-Index, der die Haufigkeit der Suche nach bestimmten Programmiersprachen im Web erfasst, belegt Java 
im iiberwiegenden Teil der letzten 10 Jahre den ersten Platz, s. http://www.tiobe.com/index.php/content/ 
paperinf o/tpci/index . html 

17 Siehe etwa http://en.wikipedia.org/wiki/Java_performance 

18 Scala enthalt eine Vielzahl von Eigenschaften, die zur Implementierung von eingebetteten Sprachen niitzlich 
sind. Dazu zahlen etwa die Umsetzung von Operatoren als Methoden und implicit conversions, vgl. Abschnitt 
2A2l S.M 
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grundsatzlich folgendes Problem: Da Generics in Java iiber type erasure implementiert sind, sind 
die Typinformationen zur Laufzeit nicht verfiigbar (sie sind nicht reifiable). Dabei gibt es eine 
Ausnahme: Bei einer Implement ierung eines generischen Interface, dessen Typ oder Typen in der 
implementierenden Klasse definiert werden (und nicht erst bei der Instanziierung von Objekten der 
implementierenden Klasse) ist es moglich, die generischen Typen zu Laufzeit abzufragen. Im Kon- 
text von TM2 sind dies etwa die Typen der Eingabe- und Ausgabeannotationen eines Agenten, 
die bei der Implement ierung des Interface definiert werden (vgl. Abschnitt 2.3 S. 12). So kon- 



nen die Typinformationen von Experimenten zur Laufzeit ermittelt und als Teil der generierten 
Dokumentation festgehalten werden (vgl. Abschnitt 2.3.6, S. 19 ) 19 . 



Aus den beschriebenen Basistechnologien ergibt sich der Rahmen fiir die Implement ierung der 
Werkzeuge und des Frameworks im weiteren Verlauf dieses Kapitels: Java als typsichere, etablierte 
Sprache fiir das zentrale Framework und dessen API, Xtext fiir die Entwicklung einer eigenstan- 
digen DSL, sowie Scala fiir die Entwicklung einer typsicheren, eingebetteten DSL. 



2.3. Ein Framework fiir typsicheres Text- Mining 
2.3.1. Fachliche Konzepte 

Zur Implement ierung der in KapitelJT] beschriebenen inhaltlichen Konzepte des Text-Mining (Anno- 
tationen, Agenten, Experimente, Evaluation) werden diese im Folgenden um Analysen, Synthesen 
und Modelle erganzt. Die grundlegenden neuen Konzepte sind dabei die lineare (Analyse) und die 
zusammenffihrende (Synthese) Interaktion zwischen Agenten. Analysen sind Prozesse, bei denen 
ein Zielagent die Ergebnisse seiner Quellen verarbeitet, und daraus neue Ergebnisse erzeugt. Syn- 
thesen beschreiben den Zusammenfluss der Ergebnisse zweier Agenten zur Bildung eines Modells. 
Experimente bestehen aus solchen Agenteninteraktionen, d.h. aus Analysen und Synthesen. Das 
Zusammenspiel dieser Begriffe beschreibt Abbildung|4j 



Typsichere Modellierung Eine im Projekt Tesla (Hermes & Schwiebert 2007) entwicklete Imple- 
mentierung der Annotationen ist die typsichere Annotation, die in Java mit Generics formuliert 
werden kann: Annotations, d.h. eine Annotation vom Typ T. Wird nun in einem Programm eine 
solche Annotation verwendet, die etwa auf den Ganzzahltyp Integer typisiert ist, kann der Java- 
Compiler garantieren, dass mit den Daten der Annotation nur giiltige Operationen ausgefiihrt 
werden. 

Im Kontext dieser Arbeit wird dieser Gedanke auf die Interaktion der Agenten ausgeweitet: 
Annotationsbasierte Agenten interagieren fiber typsichere Annotationen, und zwar in typsicheren 
Interaktionen, z.B.: Anai y sis<T>, d.h. eine Analyse vom Typ T, wobei T der analysierte Annotations- 
typ ist. Dies erlaubt eine sehr weitgehende Uberprfifung bei der Modellierung von Experimenten: 
Ffir eine solche Analyse vom Typ T etwa werden als Quellen Agenten benotigt, die Annotationen 
vom Typ T produzieren, und als Ziele Agenten, die Annotationen vom Typ T verarbeiten konnen. 
So kann schon vor der Ausffihrung die Struktur und Semantik von Experimenten validiert werden. 



19 Scala 2.8, das zur Implementierung einer DSL-Schicht in Abschnitt 2.4.2 
Zusammenhang besondere Unterstiitzung in Form von Manifests 
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verwendet wird, bietet in diesem 



die cincn cinfacheren und umfassenderen 
Zugriff auf die Typ-Informationen zur Laufzeit als mit Java ermoglichcn. 
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Abbildung 4: Zentrale API-Konzepte und Zusammenhang 



2.3.2. API der zentralen Elemente 

Im Folgenden wird die API der zentralen Elemente zur Modellierung von Text-Mining-Experiment- 
en mit TM2 beschrieben, speziell von Annotationen, Agenten und Interaktionen zwischen Agenten 
(Analysen und Synthesen), sowie zur Durchfuhrung und Evaluation von Experimenten. 

Annotationen Annotationen bilden die Grundlage des Text-Mining in der hier beschriebenen 
Auspragung. Dem ATLAS-Objektkmodell folgend, haben Annotationen im Wesentlichen einen 
Wert, eine Position und einen Typ (vgl. Abschnitt 1.2.2 S.[8]). Dieser Typ der Annotation wird in 
der TM2-API mit Generics typsicher modelliert. 

Eine normale Instanziierung einer generischen Klasse in Java erfordert eine doppelte Angabe der 
generischen Typen 20 , etwa fur eine Map, die als Schlussel Strings und als Werte Integers enthalt: 

| Map < String , Int eger > map = new HashMap < String , Int eger >() ; 

Statische Factory-Methoden bieten hier eine Alternative, da sie eine Form von Typ-Inferenz er- 
moglichen (vgl. Bloch 2008:9). So kann etwa eine Annotation vom Typ String auf folgende Weise 
instanziiert werden (unter Verwendung einer Klasse Annotations, die statische Funktionalitat fur 
Annotationen bereitstellt): 

| Annot at ion < Str ing > annotation = Annotations . create ("Firua" , 0, 1, data); 

Neben dem Typ enthalten Annotationen ihren Wert (oben etwa Firma), Start- und Endposition, 



sowie eine Referenz auf die annotierten Daten (vgl. Abschnitt 2.3.3, S. 16). Die Implementierung 



der oben verwendeten Factory-Methode sieht dabei folgendermafien aus: 

public static <T> Annotation <T> created value, int start, int end, URL data) { 
return new Annot at ion <T >( value , start, end, data); 

} 



20 Fiir Java 7 ist ein neues Sprachfeature angekiindigt, das diese Verdopplung vermeidet, s. http://openjdk. 
j ava . net/pro j ects/coin/ 
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Auf diese Weise wird die Verdopplung des Typs in eine Methode ausgelagert. Der Typ wird dabei 
automatisch durch den Typ der Variable gefullt, auf den die zuruckgegebene Instanz zugewiesen 
wird, die redundante Typdeklaration bei der Erzeugung wird dadurch iiberfliissig. 

Agenten Konzeptuell erzeugt ein annotationsbasierter Agent aus Eingabeannotationen Ausga- 
beannotationen. Dies lasst sich durch ein generisches Interface modellieren, dessen Implementie- 
rungen die konkreten, zu verarbeitenden Typen spezifizieren, etwa fur die Informationsextraktion 
mit einem Gazetteer, der Worter mit ihrer Bedeutung auszeichnet: 

|| class Gazetteer implements Agent <Word , Sense> { ... } 

Ein soldier Agent erstellt aus Word- Annotationen 5ense- Annotationen, er annotiert also Wor- 
tern mit ihrer Bedeutung. Die Methode, die diese Funktionalitat fur den Gazetteer umsetzt sahe 
in Java etwa folgendermafien aus: 

|| List < Annotation <Sense >> pr oces s ( List < Annot at ion <Word > > words) { ... } 

Tiber das vom Gazetteer implementierte Agent-Interface und dessen generische Typen kann 
gewahrleistet werden, dass eine Klasse, die einen A g ent<word,sense> implementiert, auch die entspre- 
chende Methode definiert, und eine falsch implementierte Methode (der etwa ein falscher Typ von 
Annotationen ubergeben wird) bereits vom Compiler erkannt wird. Die entsprechende Definition 
des gemeinsamen Interface aller Agenten sieht folgendermaBen aus: 

public interface Agent<I, 0> { 

public List < Annotation <0>> pr o ces s ( List < Annot at i on < I >> input); 

} 

Dies ist zu lesen als: Ein Agent mit den Typen I und O definiert eine Methode process, die als 
Parameter eine Menge von Annotationen des Typs I bekommt und als Ruckgabewert eine Menge 
von Annotationen des Typs O liefert. Ein Agent<i,o> kann also Elemente vom Typ I zu Elementen 
vom Typ O verarbeiten. 

Agenteninteraktionen Es konnen zwei Arten der Interaktion von Agenten unterschieden wer- 
den: Analysen, bei denen Annotationen eines Typs linear von Agenten verarbeitet werden, und 
Synthesen, bei denen potentiell unterschiedliche Typen von Annotationen von zwei Agenten zu 
einem Modell zusammengefuhrt werden. 

Analysen Bei einer Analyse erstellt ein Agent aus Eingabeannotationen eines bestimmten Typs 
Ausgabeannotationen eines bestimmten Typs. Daher besteht eine Interaktion von Agenten hier 
aus dem Austausch von Annotationen eines bestimmten Typs, und zwar des Ausgabetyps des 
einen Agenten (der Quelle) und des Eingabetyps des anderen Agenten (des Ziels). Entsprechend 
wird eine Analyse bei ihrer Instanziierung auf einen bestimmten Typ festgelegt, z.B. Word (unter 
Verwendung einer Klasse Analyses, die statische Funktionalitat fur Analysen bereitstellt): 

1 1 Analy si s <Word > a = Analyses . create () ; 

Eine Analyse kann aus mehreren Quell- und mehreren Zielagenten bestehen. Einer Analyse 
sollen als Quellen nur Agenten zugefugt werden konnen, die Annotationen des entsprechenden 
Typs erzeugen {Word an zweiter Position, als o eines A g ent<i,o>), etwa: 
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|| Agent <?, Word> tokenizer = new Tokenizer () ; a = a . withSour ce ( tokenizer ) ; 

Analog sollen als Ziele nur Agenten hinzugefiigt werden konnen, welche die entsprechenden 
Annotationen als Eingabe akzeptieren (Word an erster Position, als i eines A ge nt<i,o>): 

|| Agent <Word , ?> gazetteer = new Gazetteer (); a = a . withTarget ( gazetteer ) ; 

Durch die Verwendung von Generics kann sichergestellt werden, dass nur passende Agenten 
der Analyse hinzugefiigt werden. Zur Implementierung wird dazu zunachst das Interface generisch 
typisiert: 

|| interface Analysis<T> { ... } 

Als Quelle werden nur Agenten akzeptiert, welche die entsprechend typisierten Annotationen 
erzeugen (T an zweiter Position, als o eines A g ent<i,o>): 

|| Analysis <T> withSour ce ( Agent <? , T> s) { s our ce s . add ( s ) ; return this; } 

Als Ziel werden nur Agenten akzeptiert, welche die entsprechend typisierten Annotationen ver- 
langen (T an erster Position, als i eines A g ent<i,o>): 

|| Analysis <T> withTarget (Agent <T , ?> t) { t arget s . add ( t ) ; return this; } 

Die Listen, in denen intern die Agenten einer Analyse verwaltet werden sind ebenfalls entspre- 
chend typisiert: 

List < Agent <? , T>> sources; 
List < Agent <T , ?>> targets; 

Synthesen In entsprechender Weise werden Synthesen modelliert. Wir erzeugen eine Synthese, 
die auf die zu synthetisierenden Elemente typisiert ist, z.B. zur Ermittlung von Worthaufigkeiten 
(unter Verwendung einer Klasse Syntheses, die statische Funktionalitat fur Synthesen bereitstellt): 

|| Synthesis <Word , Frequency) s = Synthe ses . create () ; 

Wie bei Analysen konnen nun kompatible Agenten als beobachtete Daten (z.B. Worter) oder 
Information (z.B. Haufigkeiten) der Synthese definiert werden. Dabei sind bei Synthesen immer 
die Ausgabetypen der beteiligten Agenten (an zweiter Position eines A g ent<i,o>) relevant, da diese 
synthetisiert werden: 

Agent <? , Word> tokenizer; s = s . withDat a ( t okenizer ) ; 
Agent <? , Frequency) indexer ; s = s . wi thlnf o ( indexer ) ; 

Das Ergebnis einer durchgefuhrten Synthese ist ein Modell, das Elemente der synthetisierten 
Typen einander zuordnen kann, hier etwa Worter zu ihren Haufigkeiten: 

|| Model <Word , Frequency) frequencies = synthe s i s . model () ; 

Die Modellbildung erfolgt fiber ein Training, bei dem die zu synthetisierenden Elemente als 
Eingabe dienen: 

Model<Word, Frequency) train( 

List <Annotation <Word>> data, List < Annotation <Frequency >> info) { ... } 
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public class NE implements 
public static void mai 
public void run() { 

String output = 11 o 
Experiment x = Exp 
Agent <String , Token 
List < Analysis <?>> 
/* [Corpus] via St 
Analysis <String > i 
. withSource (new 
.withTarget(toke 
interact ions . add ( i 
/* [Tokenizer] via 
Analysis <Token > in 
.withSource(toke 
. withTarget (new 
. withTarget (new 
interact ions . add ( i 
/* Ausfuehrung und 
for (Analysis<?> i 
x . run ( ) ; 

Evaluation evaluat 
. evaluate ("data/ 
. evaluate ( "data/ 

Document ation . of (e 



Runnable { 
n(String[] args) { new NE O . run () ; } 

utput /Result " ; 

er iment s . create (" NE " , " data/ Corpus . txt " , output) 
> tokenizer = new Tokenizer (); 
interactions = new Arr ayLi st <Analys i s <?>>() ; 
ring zu [Tokenizer] : */ 
nteractionO = Analy s e s . create ( ) 
Corpus ( ) ) 
nizer ) ; 
nt er act i onO ) ; 

Token zu [Gazetteer , Counter] : */ 
teractionl = Analy se s . cr eat e ( ) 
nizer ) 

Gazetteer () ) 
Count er ( ) ) ; 
nteractionl ) ; 
Evaluierung des Experiments: */ 
: interactions) { x = x . wi thAnaly s i s ( i ) ; } 



ion = new Evaluation ( output + " . xml " ) 
Gold_Gazetteer . xml ", Gazetteer. class) 
Gold_Counter . xml " , Counter . class) ; 
xperiment , evaluation) ; 



} 



> 



Listing 1: Prinzipielle Modellierung eines einfachen Experiments iiber die Java-API von TM2, 
vgl. Abschnitt 12.41 S. |2T|fur die alternative Modellierung iiber eine DSL 



So gewahrleistet die API durch statische Typisierung von Agenteninteraktionen in Form von 
Analysen und Synthesen schon zur Kompilierzeit, dass Experimente nur mit kompatiblen Agenten 
und sinnvollen Interaktionen defmiert werden. 



Experimente Mehrere Interaktionen werden zu Experimenten zusammengefasst. So kann ein 
Experiment folgendermassen aus Analysen und Synthesen zusammengestellt und ausgefuhrt wer- 
den (unter Verwendung einer Klasse Experiments, die statische Funktionalitat fur Experimente 
bereitstellt): 

| Experiment x = Experiments . create ( . . . ) . withAnalysis (a) . withSynthesis (s) . run ( ) ; 

Ein vollstandiges Experiment kann iiber die Java-API von TM2 wie in Listing [T] erfolgen, vgl. 



die kompaktere Modellierung iiber DSLs in Abschnitt 2.4, S. 21 



Evaluierung Fur die Evaluierung von Analyseergebnissen bietet das TM2-Framework generische 
Evaluierungskomponenten, die auf Basis der beschriebenen API-Elemente erzeugte Annotationen 
mit einem Goldstandard vergleichen (als Synthese von Ergebnissen und Goldstandard). Ein Bei- 



spielexperiment, das die generische Evaluierung verwendet, findet sich in Abschnitt 3.3.4, S. 36 



vgl. die alternative Senseval- Evaluierung in Abschnitt 3.4, S. 39 



2.3.3. Interne Datenverwaltung 
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Blackboard Bei der Ausfiihrung von Experimenten schreiben die einzelnen Agenten ihre Annota- 
tionen in die gemeinsame Datenstruktur, das Blackboard (vgl. Abschnitt 1.1.3 S.|3|). Dieses ist als 



vgl. Abschnitt 

typsicherer, heterogener Container (Bloch 2008:142) umgesetzt und komplett von der Anwender- 
API isoliert, d.h. das Framework kummert sich urn die Verwaltung des Blackboards, das Abrufen 
von benotigten Annotationen, etc. Vom Anwender miissen lediglich die einzelnen Agenten imple- 
mentiert und wie oben dargestellt in Experimenten miteinander kombiniert werden. 



Ressourcen In der gesamten TM2-API werden Daten (das Korpus, Agentenressourcen, etc.) als 
URLs angegeben. Auf diese Weise konnen iiber einen einheitlichen Mechanismus sowohl lokale 
Dateien, als auch Daten auf einem Webserver (z.B. des Gutenberg-Projekts) verwendet werden. 
Auf diese Weise konnen etwa vergleichende Experimente mit lokalen und Serverdateien in einer 
einheitlichen Notation defmiert werden, z.B. fiir das Korpus: 

Corpus local = new Corpus (" f i le :/// User s / f steeg/Do cument s / f aust . txt ") ; 

Corpus remote = new Corpus (" http :// www . gut enberg . org/ f ile s / 1459 1 / 1459 1 -8 . txt ") ; 

// Verwendung von 'local' und 'remote' in vergleichendem Experiment 



2.3.4. Nebenlaufigkeit 

Die Entwicklung von Mikroprozessoren in den vergangenen Jahren ist von einer zunehmenden 
Anzahl von Kernen gekennzeichnet 21 . Es gibt zwar Ansatze zu einer alternativen Nutzung der 
wachsenden Transistordichte in Form von rekonfigurierbaren Chip-Architekturen (vgl. Berekovic 
et al. 2008), doch durch mehrere Prozessorkerne werden aktuell und auch auf absehbare Zeit die 
fortschreitenden Moglichkeiten der Miniaturisierung am Besten ausgenutzt. Um solche Hardware 
auszunutzen, muss dabei die Software die Mehrkernarchitektur unterstutzen. Bei einer rein sequen- 
ziellen Verarbeitung bieten mehrere Prozessorkerne keinerlei Vorteile. Die softwareseitige Unter- 
stiitzung mehrerer Prozessorkerne ist daher heute eines der wichtigsten Elemente zur Steigerung 
der Laufzeiteffizienz von Computerprogrammen. 

Grundlegende Herausforderungen durch Nebenlaufigkeit Eine Unterstiitzung mehrerer Pro- 
zessorkerne auf Seiten der Softwarentwickler ist nicht einfach, da paralleles Programmieren grund- 
satzlich fehleranfalliger ist als sequenzielles (Goetz et al. 2006:1). 

Eine grundlegende Unterscheidung paralleler Algorithmen kann danach erfolgen, ob von den par- 
allel laufenden Subprozessen gemeinsame Daten verandert werden oder nicht. Wird auf gemeinsame 
veranderliche Daten {mutable data) zugegriffen, muss der parallele Zugriff koordiniert 22 werden, 
sonst wird der Prozess nondeterministisch, d.h. das gleiche Programm kann bei unterschiedlichen 
Durchlaufen unterschiedliche Ergebnisse liefern (Roy Sz Haridi 2004:20). Verfahren ohne gemeinsa- 
men Zustand (shared state) sind dagegen deutlich einfacher zu realisieren, da Nebenlaufigkeit ohne 
die Notwendigkeit, gemeinsamen Datenzugriff zu koordinieren, ein vergleichsweise simples Konzept 



21 So haben einzelne Standardprozessoren inzwischen bis zu 32 Kerne; der angekiindigte Intel Knights Ferry etwa 
unterstiitzt dabei pro Kern hardwaremafiig 4 Threads und damit auf Hardwarebene bis zu 128 parallele Pro- 
zesse in einem einzelnen Prozessor (http : //www. tomshardware . com/news/knight s-f erry-corner-mic-xeon, 
11036.html), auf dem Standardanwendungen laufen (etwa auf Basis von Java, wie die hier beschriebene Imple- 
mentierung) . 

22 Gangig ist der shared memory Ansatz mit Sperren und synchronisiertem Datenzugriff (zu Details s. Roy & 
Haridi 2004 405,569). Andere Ansatze bilden etwa Actors oder software transactional memory (STM). 
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ist (Roy & Haridi 2004:14-5). Daher ist erne Formulierung von Algorithmen ohne gemeinsamen 
Zustand erstrebenswert. Zugleich ist aber wie in Abschnitt |1.1.3[ S. [3] beschrieben die Natur des 



zu losenden Problems stateful. Dies fiihrt zu einem Paradoxon bei der Implementierung von Text- 
Mining-Systemen: Probleme, deren Natur auf Kontext und gemeinsamem Wissen basieren, sollen 
moglichst atomar und funktional formuliert werden. 

Der Ansatz in TM2 ist hier, die veranderlichen Daten (das Blackboard) vom Anwender zu iso- 
lieren (vgl. Abschnitt 2.3.3, S. 16). Auf dieser Grundlage unterstiitzt das TM2-Framework soweit 
moglich Nebenlaufigkeit automatisch - mit dem Ziel, Vorgange, die logisch nebenlaufig sind, au- 
tomatisch parallel auszufuhren 23 . So werden die Moglichkeiten augeschopft, die ein Framework 
gegeniiber einer reinen Softwarebibliothek bietet: die Nutzer des Frameworks verwenden Archi- 
tektur, und klinken sich so in die nebenlaufige Verarbeitung ein, ohne dass die Komplexitat der 
Problemdomane durch die parallele Verarbeitung akzidentell gesteigert wird. 



Parallele Verarbeitung von Experimenten Einzelne Experimente sind in sich geschlossen und 
konzeptuell voneinander unabhangig. Mehrere Experimente konnen so grundsatzlich parallel ver- 
arbeitet werden, ohne dass auf gemeinsame Daten zugegriffen werden muss. Das TM2-Framework 
unterstiitzt daher eine automatische parallele Ausfiihrung mehrerer Experimente. Die Ausfiihrung 
erfolgt iiber eine statische Methode, der die Experimente ubergeben werden, z.B.: 

||Batch.run(experimentl, experiment2, experiments); 



Parallele Verarbeitung von Interaktionen Auch innerhalb eines Experiments konnen bestimmte 
Interaktionen zwischen Agenten parallel ausgefuhrt werden: Eine Analyse hat nach der Verarbei- 
tung aller ihrer Quellen alle Annotationen gesammelt, die von den Zielen benotigt werden. So 
konnen alle Ziele einer Analyse ihre Daten ohne gemeinsamen Zustand parallel verarbeiten. Daher 
verarbeiten im TM2-Framework die Zielagenten einer Analyse ihre Eingaben automatisch neben- 
laufig (z.B. unterschiedliche Tagger, die auf Basis der Tokens eines einzigen Tokenizers arbeiten). 

2.3.5. Retrieval 

Ziele Die in Experimenten generierten Annotationen sollen neben der automatischen Auswertung 
bei einer Evaluierung auch etwa fur eine erweiterte Suche in den analysierten Daten verwendet 
werden konnen. Fur das in Kapitel [T] beschriebene exemplarische Gesamtziel eines semantischen 
Information- Retrieval ist eine solche intelligente Suche sogar der eigentliche Zweck des Text-Mining. 
Dazu unterstiitzt die TM2-API eine Suche in den Annotationen. Dabei kann nach einem Wert in 
den Annotationen eines bestimmten Agenten gesucht werden, wahrend die korrespondierenden 
Annotationen eines anderen Agenten als Ergebnis geliefert werden konnen. 

Mithilfe dieses generischen Mechanismus sind unterschiedliche Anwendungsszenarien denkbar. 
So kann etwa in den Annotationen eines POS-Taggers nach Verben gesucht werden und die kor- 
respondierenden Annotationen des Tokenizers ausgegeben werden (wir erhalten die als Verben 
getaggten Wortformen). Es konnen aber auch die korrespondierenden Annotationen eines Indexers 
ausgegeben werden (und wir erhalten die Haufigkeit von Wortformen, die Verben sind), etc. Beim 

23 Diese Verbindung von domanenspezifischer Modellierung (im spateren Verlauf dieses Kapitels auch in Form von 
DSLs) und automatischer Nebenlaufigkeit wird auch in anderen Bereichen und in groBerem MaBstab (in Bezug 
auf die Parallelitat) verfolgt, vgl. Chafi et al. (2010). 
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Retrieval konnen so die von den verschiedenen Agenten gesammelten Informationen flexibel genutzt 
und neu kombiniert werden: jeder Agent hat nur seine spezifische Aufgabe erfiillt (der Tokenizer 
hat zerlegt, der Tagger getaggt, der Indexer gezahlt), aber die Ergebnisse lassen sich zu neuen, 
so zuvor nicht definierten Aufgaben verbinden. Annotationen stellen so eine Strukturebene in den 
Daten dar, die quasi klassisches Data-Mining (im Sinne einer Analyse strukturierter Daten) auf 
Texten ermoglicht. 



API Die Retrieval-API unterstiitzt eine typsichere Suche. So muss beim Suchen in den Annota- 
tionen eines bestimmten Agenten ein Objekt zum Suchen verwendet werden, das den Typ hat, den 
der Agent produziert und nur ein solches - was wie oben bei Experimenten zur Folge hat, dass der 
Compiler sicherstellt, dass nur sinnvolle Suchen moglich sind. 

Tiber die API kann etwa nach den Bedeutungen einer Wortform gesucht werden (Suche nach 
Tokenizer- Ausgabetyp String, Ergebnis ist Gazetteer- Ausgabetyp Sense): 

|List<Sense> senses = retrieval . f ind (" Rhine " , Tokenizer . class ). by ( Gazetteer . class ) ; 

Oder umgekehrt, eine Suche nach den Wortformen einer Bedeutung (Suche nach Gazetteer-Aus- 
gabetyp Sense, Ergebnis ist Tokenizer- Ausgabetyp String): 

| List <String > tokens = r etrieval . f ind ( Sens e . NAME , Gazett eer . clas s ). by ( Tokenizer . class ) ; 

Oder etwa eine Suche nach Bedeutungen von Wortformen, die zweimal vorkommen (Suche nach 
Indexer- Ausgabetyp Integer, Ergebnis ist Gazetteer- Ausgabetyp Sense): 

|List<Sense> senses = r et r i e val . f ind (2 , Indexer . clas s ). by ( Gazett eer . clas s ) ; 

Als Anwendungsbeispiele dieser API enthalt die TM2- Software eine einfache Konsolenapplikati- 
on, die eine textuelle Nutzung dieser Retrievalfunktionalitat ermoglicht. Als Briicke zwischen einer 
textuellen Eingabe und der typsicheren Such-API kann fiir eine solche Anwendung die optionale 



String-Reprasentation von Annotationswerten dienen (vgl. Abschnitt 2.3.7, S. 20). 



2.3.6. Dokumentationsgenerierung 

Die generierte Dokumentation von Experimenten im TM2-Framework besteht aus einer Beschrei- 
bung des Versuchsaufbaus, den verwendeten Daten, den Verfahren, die auf die Daten angewendet 
wurden (d.h. den Agenten), sowie den so ermittelten Resultaten in Form von Annotationen und 
Evaluationsergebnissen. 



Abbildungen Auf Basis des Objektmodells eines Experiments, d.h. auf Basis seines Aufbaus aus 
Interaktionen und Agenten, kann eine Visualisierung des Experiments fiir die Dokumentation ge- 
neriert werden. In TM2 erfolgt dies auf Basis des von AT&T entwickelten Graphviz-Pakets 24 . Die 
Beschreibungen der zu generierenden Abbildungen in der Graphenbeschreibungssprache DOT 25 
werden mit EMF und der Template- Sprache JET 26 generiert. Die Abbildungen zu den verschiede- 
nen Experimenten in Kapitel [3] (z.B. Abbildung 13, S. 44) wurden auf diese Weise erstellt. 



24 Graphviz, http : //www . graphviz . org/ 

25 DOT, http://en.wikipedia.org/wiki/DOT_language 

26 JET, http://www.eclipse.org/modeling/m2t/ 
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2.3.7. HTM L-Ausgabe iiber WikiText 



Die Gesamtdokumentation wird in Fom eines HTML-Dokuments generiert, welches mit JET (s.o.) 
und Mylyn WikiText 27 erstellt wird. Dabei konnen die verschiedenen Ressourcen (wie Input-Texte, 
XML-Export von produzierten Annotationen oder Goldstandard-Annotationen) mittels Hyper- 
links verbunden und Evaluationsergebnisse tabellarisch aufbereitet werden. So erhalt man auto- 
matisch eine sehr kompakte und niitzliche Dokumentation zu einem Experiment oder einer Serie 



von Experimenten (vgl. Experimente in Kapitel [3] und Anhang A. 4 speziell Abb. 14 S. 44). 

Eine erste Implementierung der Dokumentationsgenerierung mit LaTeX stellte sich als schwerge- 
wichtige Losung heraus: Die LaTeX- Abhangigkeit ist nicht trivial (eine vollstandige TeX-Installation 
umfasst meist iiber 1 GB) und der Aufruf des nativen pdflatex-Piogra,mms ist fehleranfallig und 
plattformabhangig. Eine flexiblere, rein Java-basierte Alternative stellt die Generierung von Wiki- 
Markup dar, welches mithilfe der WikiText-Komponente von Mylyn in HTML exportiert wird. 
WikiText kann die generierte Zwischenreprasentation alternativ in andere Formate wie DocBook 28 , 
DITA 29 oder PDF (iiber XSL-FO) 30 transformieren. 



XML-Export Annotationen konnen in TM2 in ein simples XML-Format exportiert werden. Aus 
diesem lassen sich die Annotationen wieder als Objekte instanziieren. Als ein XML-Attribut ei- 
nes Annotationselements wird dafur die serialisierte und als Base64-String codierte 31 Version des 
Wertes der Annotation gespeichert. 

Dieses Vorgehen hat zwei Vorteile: 1. Aus den textuellen XML-Dateien konnen so beliebig kom- 
plexe Objekte instanziiert werden. 2. Bei der Entwicklung von Komponenten wird durch die Forde- 
rung einer Implementierung des Serializable-Interface bei der Typisierung der Agenten-Daten vom 
Java-Kompiler schon zur Kompilierzeit sichergestellt, dass die verwendeten Daten mit Java-Mitteln 
persistiert werden konnen. 

Uber die API konnen auf diese Weise Annotationen persistiert und typsicher geladen werden: 

Agent <? , Sense> agent = new Gazetteer (); 

/* ...Experiment, 'agent' schreibt Annotationen die wir speichern und laden koennen: */ 
Annot at i onWr i t er w = new Annot at ionWr it er ( blackboard , dat a ) . wr it e Annot at i ons ( loc at i on ) ; 
List < Annotation <Sense >> senses = new Annot at ionReader ( locat ion ). readAnnot at ions ( agent ) ; 

Fur die Verwendung von Annotationenen, die in einer anderen Sprache als Java oder manuell 
erstellt wurden (z.B. fur einen Goldstandard), und die daher keine serialisierten Objekte enthalten, 
konnen die Objekt auch aus einer menschenlesbaren Darstellung instanziiert werden. Dazu muss 
der zu instanziierende Datentyp einen Konstruktor mit einem einzelnen String-Parameter haben, 
der beim Laden der Annotationen von TM2 iiber die Java Reflection API aufgerufen wird. Fiir 
die gangigen Datentypen wie Strings, Ganzzahlen und Fliefikommazahlen ist dies automatisch 
gewahrleistet. Fiir eigene Datentypen muss ein entsprechender Konstruktor erstellt werden, wenn 
eine Instanziierung iiber menschenlesbare Darstellungen gewiinscht ist. 



27 Mylyn WikiText, http://wiki.eclipse.org/Mylyn/WikiText 

28 DocBook, http://www.docbook.org/ 

29 DITA, http://dita.xml.org/ 

30 XSL-FO, http://en.wikipedia.org/wiki/XSL_Formatting_Objects 

31 Die Base64-Kodierung ermoglicht cine Abbildung von Binardaten auf den ASCII-Zcichcnsatz. 



20 





experiment 




+data 




+agents 






1..N 


agent 


+name 


+annotations 






1..N 




annotation 




+start 




+end 




+label 




+obj 



Abbildung 5: Logische Struktur der XSD des TM2-Exportformats 



Exportformat Die Struktur des Exportformats wird mit einer XSD 32 definiert. Die logische Struk- 
tur des XML-Formats beschreibt Abb. [5j die vollstandige XSD findet sich in Anhang A. 2. 13 , S. 58 



Durch die Validierung gegen eine XSD konnen fehlerhafte Eingabedateien friih erkannt werden, 
was eine Form des Fail-Fast-Konzepts (Shore 2004) darstellt, d.h. ein moglichst friihes Erkennen 
von Fehlern zur Vereinfachung der Fehlersuche. 

Im Zusammenspiel mit Werkzeugen bietet eine XSD zudem die Moglichkeit einer Validierung 
beim manuellen Erstellen von XML-Dateien (z.B. fur einen Goldstandard) in einem validierenden 
Editor, etwa im XML-Editor von Eclipse. So stent die Verwendung einer XSD die Grundlage fiir 
eine vielfaltige Verwendung der mit TM2 erzeugten XML-Annotationsdateien dar (vgl. Abschnitt 



4.2.1, S. 48). 



2.4. Textuelle Modellierung im Text-Mining 

Experimentserien sollen in einer domain-specific language (DSL) beschrieben werden, welche die 
Funktionalitat der API in einer kompakteren Form zuganglich macht. Zur Implementierung von 



DSLs lassen sich zwei Ansatze unterscheiden: eigenstandige und eingebettete DSLs (vgl. 2.2.2, S. 



10). In dieser Arbeit werden beide Ansatze verfolgt und verglichen: zum Einen eine eigenstandige 
DSL mit dem auf ANTLR (Parr 2007) basierenden Xtext-Framework 33 des Eclipse Modeling Pro- 
ject, zum Anderen eine eingebettete DSL in der JVM-basierten, statisch typisierten Sprache Scala. 



Beide Ansatze werden in Abschnitt 2.4.4, S. 27 hinsichtlich der Komplexitat ihrer Umsetzung und 



der praktischen Anwendbarkeit verglichen. 



32 XML Schema Definition, http://www.w3.org/XML/Schema 

33 Xtext Language Development Framework, http://eclipse.org/xtext 
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Experiment " NE " Data " input / Corpus " Out " output /Result " Import "tm2. agents" 

/* Als Erstes wird das Korpus tokenisiert: */ 
Corpus -> String -> Tokenizer . 

/* Dann werden die Token mit Eigennamen versehen und indexiert : */ 
Tokenizer -> Token -> Gazetteer Indexer . 

/* Schliesslich koennen wir z.B. die Eigennamen evaluieren: */ 
Evaluate Gazetteer Against "input/Gold" 



Listing 2: Experiment in der eigenstandigen Xtext-DSL 



2.4.1. Eigenstandige DSL 



Modellierung Eine Modellierung der Interaktionen wie in Abschnitt 2.3, S. 12 fiir die API be- 
schrieben (vgl. Listing [Tj S. 16) ist aus Sicht eines Java-Entwicklers nicht ungewohnlich, wiirde 
man jedoch unvorbelastet 34 anfangen, ist eine typisierte Interaktion von Agenten in der einfachs- 
ten textuellen Form etwa so modellierbar: 



Tokenizer -> Token -> Gazetteer. 



D.h. der Tokenizer produziert Token-Instanzen, die vom Gazetteer verarbeitet werden. Dement- 
sprechend kann mit Xtext eine Sprache implementiert werden, in der Experimente wie in Listing 
[2j S. [22] modelliert werden konnen. Jede Zeile nach der Definition der Metadaten in der ersten 
Zeile entspricht dabei einer Interaktion. Der Operator -> zwischen den Agenten beschreibt den In- 
formationsfluss in der Interaktion: von den Agenten, die als Quellen fungieren (oben z.B. Tokenizer), 
iiber den Typ der ausgetauschten Daten (oben z.B. Token), zu den Zielagenten (oben z.B. Gazetteer). 
Jede Interaktion schliefit mit einem Punkt ab. Die Angabe der Daten, die zwischen den Agenten 
ausgetauscht werden, stellt eine Form von Typisierung dar, die bei der Weiterverarbeitung auto- 



matisch verifiziert werden konnte (vgl. Abschnitte 2.2.1, S.[9]und 2.4.2, S. 24). Eine solche Sprache 
ist deklarativ, da sie den Aufbau eines Experiments beschreibt, das dann gestartet werden kann - 
im Gegensatz zu einer prozeduralen DSL, welche die Ausfiihrung eines Programms steuert 35 . 



Implementierung mit Xtext Xtext 36 ist ein auf dem Eclipse Modeling Framework (EMF 37 ) ba- 
sierendes Framework zur Entwicklung von DSLs. Ausgangspunkt bei der Entwicklung einer DSL 
mit Xtext stellt die Grammatik der zur entwickelnden Sprache dar, die in einer EBNF-artigen 38 
Syntax beschrieben wird. Ausgehend von dieser Grammatik generiert Xtext fiir die Sprache ein 
EMF-Metamodell 39 , einen Parser und graphische Elemente wie einen Editor mit Fehleruberprii- 
fung, Syntaxfarbung, kontextsensitiver Hilfe, Strukturiibersicht, etc. Dies macht sowohl die Ent- 
wicklung von Sprachen (inklusive passenden Werkzeugen), als auch die Integration mit bestehenden 

34 Eine solche unvorbelastete Herangehensweise ist ein Grundgedanke des DSL-Ansatzes - ganz im Sinne Witt- 
gensteins: Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt (Wittgenstein 1921), vgl. Notation 
And Thinking, http://rjlipton.wordpress.com/2010/ll/30/notation-and-thinking/ zur Bcdcutung von 
Notation fiir den Fortschritt in der Mathematik. 

35 Eine solche prozedurale DSL wird etwa in Bilagher (2006) fur Tesla beschrieben. 

36 Xtext Language Framework, http://www.eclipse.org/xtext 

37 Eclipse Modeling Framework, http://eclipse.org/emf 

38 Extended Backus-Naur Form, eine Syntax zur Spezifikation von Grammatiken 

39 Das Metamodell bildet das Schema fiir die EMF-interne Representation der geparsten Modelle 
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Experiment : /* Attribute eines Experiments: Name, Daten , Ausgabeort */ 
"Experiment" name = STRING "Data" corpus = STRING "Out" output = STRING 
/* Es verwendet Agenten und Datentypen aus einem spez if iz i er t en Package: */ 
"Import" ( imports+=STRING) + 

/* Es besteht aus einer Menge von Int er akt i onen : */ 
(interactions+=Interaction)+ 

/* Es enthaelt optional eine Evaluierung : */ 

("Evaluate" ( eval Agent s += ID ) + "Against" evalLocat ion= STRING )? ; 

/* Jede Interaktion hat Quellen , einen Typ und Ziele ... */ 

Interaction : sour ce =Sour ce "->" type=ID "->" target =Target 

/* ... potentiell mehrere Quellen ... */ 

Source : ( sourceAgents +=Agent ) + ; 

/* ... und potentiell mehrere Ziele ...:*/ 

Target : ( t ar get Agent s + = Agent ) + ; 

/* . . . alle dargestellt durch Agenten: */ 

Agent : name=ID; 



Listing 3: Grammatik der eigenstandigen Xtext-DSL 



EMF-Werkzeugen sehr einfach. Die Definition der Grammatik fiir die oben dargestellte Sprache in 



Xtext ist dabei sehr iibersichtlich (s. Listing |3j S. 23). Mithilfe des generierten Parsers kann ein 
Experiment wie in Listing [2] eingelesen und anschlieBend ausgefiihrt werden. In dem generierten 
Editor konnen solche Experimente komfortabel erstellt werden. 

Ubersetzung Ein Nachteil der beschriebenen Xtext-DSL gegeniiber der direkten Nutzung der 
Java-API ist, dass der Typ der Interaktionen lediglich als String in der Grammatik modelliert 
wurde und der generierte Parser so nicht automatisch eine Uberpriifung der Korrektheit der Ty- 
pen durchfiihrt. Um die Vorteile der problemnahen Modellierung in einer DSL mit der statischen 
Typisierung und den Uberprufungen zur Laufzeit in der beschriebenen Java-API zu verbinden, 
kann die DSL z.B. in die Java- Version iibersetzt werden 40 . Diese generierte Form nutzt die Java- 
API von TM2. Sie kann vom Java-Compiler uberpruft werden und entsprechende Fehlermeldungen 
zuriickgeben. Auf diese Weise wird eine Duplikation der Regelmodellierung verhindert (statt diese 
- neben der Java-API - noch einmal mit anderen Mitteln fiir die DSL zu implementieren). Durch 
die Integration des generierten Xtext-Editors in Eclipse ist eine rudimentare Integration mit der 
Java-Entwicklungsumgebung in Eclipse bei diesem Ansatz automatisch vorhanden. 

Eine Transformation des textuellen Modells in Java ist mithilfe von Xpand- Templates sehr un- 
kompliziert moglich: Xpand ermoglicht die typsichere Konvertierung des geparsten Modells (hier 
aus der DSL) in eine alternative textuelle Form (hier in Java-Code). In analoger Weise kann aus 
dem Modell auch eine graphische Aufbereitung mit Graphviz erfolgen, die zur Generierung der 



Ubersichtsdokumentation verwendet werden kann. In Anhang A. 2. 7, S. 55 finden sich die verwen- 
deten Xpand- Templates und ein komplettes Beispiel aus Eingabe-DSL, Templates und Java- sowie 
DOT-Ergebnissen. 

Fazit externe DSL Abbbildung [6] zeigt die Komponenten der beschriebenen externen DSL mit 
Xtext und Xpand im Gesamtzusammenhang des TM2-Frameworks. Vorteile einer solchen Losung 



40 Alternativen bilden etwa Xtext constraint checks oder das neuere Xtext Typesystem Framework (http:// 
voelterblog. blogspot . com/2010/08/xtext- typesystem- f ramework. html ). 
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Abbildung 6: Gesamtubersicht und Zusammenspiel der TM2-Komponenten bei einer Losung mit 
der eigenstandigen Xtext-basierten DSL 



sind die Integration in EMF-basierte Werkzeuge und die hervorragende Werkzeugunterstiitzung - 
sowohl beim Erstellen von Grammatik und Code-Generatoren bei der Implementierung der DSL, 
wie auch zur Erstellung textueller Modelle in der Zielsprache. Die enge EMF- bzw. allgemeine 
Eclipse-Integration kann je nach Anwendungsfall jedoch auch einen Nachteil darstellen - etwa wenn 
fur eine zu entwickelnde DSL weder Java- noch Eclipse-Integration erforderlich sind. Zudem ist 
der Aspekt der typsicheren Modellierung hier nur indirekt umgesetzt, namlich durch die Nutzung 
der typsicheren Java-API in dem aus der DSL generierten Code. 

2.4.2. Eingebettete DSL 

Zum Vergleich mit der beschriebenen Implementierung einer eigenstandigen DSL mit Xtext wird 
dieser im Folgenden eine eingebettete, typsichere DSL in Scala gegeniibergestellt. 

Scala fiir eingebettete DSLs Scala (A scalable language, s. Odersky et al. 2008) ist eine statisch 
typisierte, funktional-objektorientierte Hybridsprache, die auf der JVM lauft. Operatoren sind in 
Scala als Methoden implementiert - so wird etwa ein Aufruf wie i + 2 vom Scala- Compiler in (i) .+(2) 
umgewandelt, d.h. + ist der Name einer Methode der Klasse von 1. Methoden konnen aus beliebigen 
symbolischen oder alphanumerischen Unicode-Zeichen bestehen (d.h. auch etwa "v"), sowie in Infix- 
oder Prafix-Notation verwendet werden. Dies ist ein Grund warum sich Scala hervorragend zur 
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Definition eingebetteter DSLs eignet 41 . 

Implizite Typumwandlung und Nutzung der typsicheren API Scala ermoglicht dariiber hin- 
aus eine implizite Typumwandlung. Durch solche implicit conversions werden Objekte eines Typs 
implizit in Objekte eines anderen Typs konvertiert. Dies ermoglicht eine Erweiterung der Funktio- 
nalitat von Klassen, ohne die Klassen selbst zu verandern. Scala verwendet diese Funktionalitat 
etwa, um Java-Strings um zusatzliche Methoden zu erweitern. Die in Scala implementierte DSL- 
Schicht kann daher auf die Java-Klassen der TM2-API zugreifen und fiber implicit conversions die 
Java-Klassen mit der Scala-DSL anreichern. So ermoglicht die implizite Typumwandlung in TM2 
die Verwendung von in Java implementierten TM2-Agenten mit der Syntax der Scala-DSL. Scala 
ist eine optimale Sprache ffir diesen Anwendungsfall, da sie neben den dargestellten generellen 
Moglichkeiten bei der Implementierung einer DSL zudem wie Java statisch typisiert ist und so au- 
tomatisch die Vorteile der typsicheren Java- API nutzen kann. Diese Regeln der Java-API mfissten 
bei der Verwendung einer externen DSL komplett neu definiert werden, oder konnten wie oben 



beschrieben nur indirekt genutzt werden (vgl. Abschnitt 2.4.1, S. 23, vgl. Abschnitt 2.2.2, S. 11) 



Enge Scala- Integration Eine eingebettete DSL ermoglicht zudem grundsatzlich die Verwendung 
von alien Moglichkeiten der Basissprache und ihrer Werkzeuge, wie die Definition von Variablen, 
die Verwendung (und Entwicklung, vgl. Odersky et al. 2008:16111.) von Kontrollstrukturen, oder 
interaktives Debugging. Im Kontext von TM2 ist etwa ein sehr nfitzliches Scala-Sprachfeature die 
vielseitige /or-Syntax (vgl. Odersky et al. 2008:486), mit der kombinatorische Probleme sehr kom- 
pakt beschrieben werden konnen - etwa komplexe Experimente mit variablen Teilen zur einfachen 
Definition von Experimentserien (s. Abb. [7J S. 26, vgl. Abschnitt 3.4.4, S. 42). 



Diese enge Integration in die Basissprache kann auf anderer Ebene auch als Nachteil gesehen 
werden: Fehlermeldungen beziehen sich semantisch immer auf die Basissprache, nicht die entwickel- 
te DSL. Eine eigenstandige DSL bietet hier mehr Moglichkeiten fur angepasste Fehlermeldungen, 
die allerdings immer eine separate Modellierung der Regeln voraussetzen (und damit hier eine 
Duplikation der Regeln aus der Java-API, s.o.). 

Modellierung von Interaktionen In Anlehnung an die Modellierung von Interaktionen in der 
eigenstandigen DSL werden auch in der eingebetteten DSL Interaktionen mit -> dargestellt. Im 
Unterschied zur eigenstandigen DSL verwenden wir hier die eingebaute Typisierung von Scala, 
bzw. der zugrunde liegenden Java- API, z.B. bei der Modellierung einer Analyse: 

| tokenizer -> gazetteer : Analysis [Token] 

In vergleichbarer Weise konnen in der Scala-DSL Synthesen definiert werden, z.B. zur Ermittlung 
von Worthaufigkeiten: 

I (tokenizer, indexer) -> model : Synthesis [Token , Frequency] 



41 Scala bietet iiber die hier dargestellten Merkmale hinaus unterschiedliche weitergehende Unterstiitzung fur DSLs, 
sowohl durch grundlcgende Sprachmerkmale (etwa Moglichkeiten zur Definition von kontrollstrukturartigen 
Bibliotheken, vgl. Odersky et al. 2008 161ff.), als auch durch spezialisierte Bibliotheken (etwa in Form von 
combinator parsing, vgl. Odersky et al. 2008:6190'.). 
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Modellierung von Experimenter! Durch eine Verkniipfung von Interaktionen mit dem selbst 
definierten Operator i konnen wir mit der Scala-DSL z.B. einfache Experimente ohne Evaluierung 
definiereri, die wir mit dem ebenfalls selbst definierten Operator ! ausfiihren konnen: 

I val experiment = corpus -> tokenizer I tokenizer -> gazetteer ! 



Wir konnen iiber die Scala-DSL auch - wie in Abschnitt 2J3 S. 12 fiir die Java- API beschrieben - 
flexibel in den Annotationen eines Experiments suchen, etwa nach den Tokenizer-Entsprechungen 
von Gazetteer- Annotationen mit dem Wert NAME 42 : 

| experiment find (Sense. NAME, gazetteer) by tokenizer 

Neben der manuellen Suche in den erzeugten Annotationen kann das Ergebnis eines Experiments 
auch automatisch evaluiert werden, z.B. zur Evaluierung einer Informationsextraktion mithilfe 
eines Goldstandards: 

| val experiment = corpus -> tok I tok -> (ie, gold) I (ie, gold) -> evaluation ! 



Experimentserien Zur Modellierung von Experimentserien unter Verwendung der Scala-DSL de- 
finieren wir zunachst die beteiligten Agenten mit den unterschiedlichen, zu vergleichenden Kon- 
figurationen und definieren dann deren einheitliches Zusammenspiel in den Experimenten. Die 
generelle Form von Experimentserien in der Scala-DSL ist in Abb. [TJdargestellt. Dabei beschreibt 
der /or-Block die unterschiedlichen Konfigurationen der im yield-Block definierten Experimente, 
die durch den optionalen run-Block ausgefuhrt und automatisch dokumentiert werden. 

run { for { <conf iguration> } yield { <experiment> } } 

Abbildung 7: Grundlegende Form von Experimentserien in der Scala-DSL 



Die Beschreibung in Listing [4], S. 27 etwa verwendet zwei unterschiedliche Korpora und zwei un- 
terschiedliche Praprozessoren. Die Permutationen der Konfigurationsparameter stellen dabei die 
unterschiedlich konfigurierten Experimente dar, die auf Basis einer solchen Beschreibung parallel 
ausgefuhrt und vergleichend dokumentiert werden (d.h. hier z.B. 4 Experimente: Works Of Shakes- 
peare und WorksOf Goethe jeweils mit einem RuleBasedTokenizer und einem TrainableTokenizer) . 

Diese DSL wird in Kapitel [3] fiir die Durchfiihrung von Beispielexperimenten zur Informati- 
onsextraktion (Abschnitt 3.1, S. 28) sowie zur WSD mit Pseudoambiguitat (Abschnitt 3.3.4, S. 



36) und Senseval-Daten (Abschnitt 3.4 S. 39) verwendet. Die Implementierung der eingebetteten 
Scala-DSL ist in Anhang |A.2.8[ S. [56]dargestellt. 



2.4.3. Editor 

Der Editor, ein zentraler Teil der Werkzeugunterstiitzung fiir die Modellierung mit einer DSL, ist 
bei einer eingebetteten Sprache in der Regel schon vorhanden, und im besten Fall ausgereift. So 
bedeutet die Entwicklung einer eingebetteten TM2-DSL in Scala im Grunde die Entwicklung einer 
diinnen Scala-API, die auf die bestehende Java-API aufbaut (indem sie diese aufruft und mit einer 



42 Die Verwendung der Java-API aus Scala kann in einem solchen Fall durch Weglassen der Punkte vereinfacht 
werden. 



26 



run { 
for { 

corpus <- List (new WorksOf Shakespeare , new WorksOf Goethe ) 
tokenizer <- List (new RuleBasedTokenizer , new Tr ainableTokenizer ) 
gazetteer = new Gazetteer 
gold = new GazetteerGoldStandard 
evaluation = new SimpleEvaluation 
} yield { 

corpus -> tokenizer I 

tokenizer -> (gazetteer, gold) I 

(gazetteer, gold) -> evaluation 

} 

} 

Listing 4: Beispiel fur Experimentserie in der Scala-DSL 



spezialisierten, domanenspezifischen Syntax zuganglich macht). Durch die sehr weitgehende Ge- 
nerierung von Werkzeugen beim Erstellen von eigenstandigen DSLs mit Xtext ist der Unterschied 
in diesem Bereich nicht mehr so grofi wie bis vor Kurzem, dennoch haben hier eingebettete DSLs 
einen generellen Vorteil, da die Werkzeugunterstfitzung nicht selbst erzeugt und angepasst werden 
muss, und sehr weitgehend sein kann (z.B. automatisches Refactoring, interaktives Debugging, 
etc.). 

2.4.4. Fazit DSL 

Die Verwendune; von Scctlci zur Implementierung einer DSL fiir TM2 bestatigt, dass mit Scala 
Anwendungsfalle mit einer eingebetteten DSL umsetzbar sind, fiir die in anderen Sprachen eigen- 
standige DSLs eingesetzt werden mfissen (Odersky et al. 2008:447). Die Umsetzung als eingebettete 
DSL macht dabei die Eigenentwicklung vieler Komponenten fiberflfissig, etwa zur Unterstiitzung 
von statischer Typisierung oder von Werkzeugen, etwa in Form von Editoren und Debuggern. Mit 
diesen Vorteilen macht Scala eingebettete DSLs generell zu einer sehr attraktiven Alternative ge- 
geniiber eigenstandigen DSLs - selbst ohne die Nutzung weitergehender Moglichkeiten von Scala 
bei der Entwicklung von DSLs, etwa die Definition neuer Kontrollstrukturen (vgl. Odersky et al. 
2008:161ff.) oder combinator parsing (vgl. Odersky et al. 2008:619ff.). 

Die beschriebenen Umsetzungen von DSLs zur typsicheren Modellierung im Text-Mining zei- 
gen ein Spannungsfeld zwischen der Forderung nach statischer Typisierung zur Umsetzung der 
Konzepte aus Kapitel [T] und der haufig dynamisch typisierten Natur von DSLs. Hier umgesetzt 
wurden zwei Ansatze: 1. Eine eigenstandige DSL, die mit Xtext implementiert wurde und die 
fiber Xpand zu Java-Code kompiliert wird. Dieser wird mit dem Java-Compiler verarbeitet, dessen 
Meldungen fiber fehlerhafte Typisierung den Benutzer der DSL bei der Modellierung unterstfitzen 
konnen. 2. Eine eingebettete Scala-DSL, welche die Typisierung von Scala nutzt und durch ihre 
Java-Kompatibilitat die Java-Klassen und -Interfaces des TM2-Frameworks direkt nutzen kann. 

Abbildung [8] gibt einen Uberblick fiber die Interaktion der alternativen Implementierungen der 
DSL mit der zugrundeliegenden Java-API. Die Experimente in Kapitel [3] wurden mit der leicht- 
gewichtigen 43 , typsicheren Scala-DSL implementiert, die zu diesem Zweck ausgebaut wurde und 

43 Die Scala-DSL ist insgesamt lcichtgewichtiger als die Xtext-Losung, da neben Scala selbst keine zusatzlichen 
Bibliothckcn oder Frameworks notwcndig sind, wahrend der Xtext- Ansatz gerade von seiner starken Integration 
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Abbildung 8: Unterschiedliche Nutzung der Java-API durch Xtext- und Scala-DSL 



so die Basis der TM2-Werkzeuge bildet. Fur Details zur prototypischen Xtext-DSL s. Hinweise in 



Anhang A.l, S. 53 



3. Typsichere Modellierung von Klassifikationsproblemen 
3.1. Informationsextraktion als einfiihrendes Beispiel 



Im folgenden Abschnitt (3.1.1) wird aufbauend auf eigenen Vorarbeiten (Steeg 2007) eine einfache 



Form der Informationsextraktion dargestellt, die im anschlieBenden Abschnitt (3.1.2, S. 30) als 
einfiihrendes Beispiel mit TM2 implementiert wird. 

3.1.1. Semantische Annotation und Informationsextraktion 

Das Ergebnis einer Informationsextraktion aus Texten kann als semantische Annotation festgehal- 
ten werden, bei der Textabschnitte mit ihrer Bedeutung annotiert werden, etwa Rhein als 'Fluss'. 
Eine solche semantische Annotation ist fur verschiedene direkte Anwendungsfalle hilfreich (z.B. 
bei der Suche in den Texten), und fur zahlreiche Probleme der maschinellen Sprachverarbeitung 
sogar notwendig (z.B. fur die maschinelle Ubersetzung von ambigen Wortern in der Quellsprache, 
etwa engl. bank). 

Eine einfache Form der Informationsextraktion ist die Eigennamenerkennung (named entity re- 
cognition), bei der in einem Text Eigennamen bestimmter Kategorien gesucht werden, z.B. in bio- 
logischen Texten Spezies, in medizinischen Medikamente oder bei Nachrichten Personen, Firmen 



in andere Bibliotheken und Frameworks (speziell EMF und Eclipse allgcmcin) profiticrt. 
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oder Orte. Eigenname ist dabei hier, wie bei Frege (1892:27), die Bezeichnung eines bestimm- 
ten einzelnen Gegenstandes, wobei diese Bezeichnung aus einem einzigen oder auch aus mehreren 
Wortern 44 bestehen kann. 



Wortlisten zur Annotation Eine einfache Umsetzung einer solchen Eigennamenerkennung kann 
durch Listen mit den Eigennamen 45 erfolgen. Hierbei wird pro Kategorie eine Liste angelegt, z.B. 
fiir alle Fliisse oder alle Stadte, welche dann konkrete Eintrage enthalten, wie Rhein bzw. Koln. 

Wortlisten bilden eine gut wartbare, flexible Form eines maschinenlesbaren Lexikons. So ist etwa 
neben der Nutzung zur Informationsextraktion eine Integration von POS-Tags ebenso denkbar wie 
jede andere Form von Klassiflkation: es mussen lediglich entsprechende Wortlisten (manuell oder 
automatisch) erstellt werden. Dabei ist keine Modifikation des Programms notig. Es handelt sich 
hierbei um eine Form von Metaprogrammierung oder dynamischer Konfiguration, bei der das 
Programm die Abstraktionen enthalt, wahrend die Metadaten - hier in Form der Listen - die 
Details bereitstellen (vgl. Hunt & Thomas 2003:135). 



Ambiguitat als praktisches Problem Ware in menschlicher Sprache jeder Wortform eindeutig 
eine Bedeutung zugeordnet, ware eine semantische Annotation von Texten so ohne grofie Schwie- 
rigkeiten automatisierbar - einfach durch ein Abrufen der Bedeutung einer Wortform in einer 
Datenstruktur, die einem Worterbuch entspricht und die auf Grundlage der Listen gefiillt wurde. 
Die Namen der Listen bilden dabei die semantische Kategorie oder Bedeutung der in der Liste 
enthaltenen Worter. Beim Vorfinden einer Wortform (etwa Rhein oder Koln), lasst sich diese so 
mit ihrer Bedeutung auszeichnen (etwa als 'Fluss' bzw. als 'Stadt'). 

Mehrdeutige Worter jedoch tauchen in mehreren Listen auf, so konnte etwa Bank in den Listen 
'Mobel' (mit Eintragen wie Tisch und Stuhl) und 'Ort' (mit Eintragen wie Kino oder Supermarkt) 
enthalten sein. Daraus ergibt sich folgendes Problem: Wie sollen Eintrage, die in mehreren Listen 
enthalten sind, annotiert werden? Denn im Kontext des Vorkommens ist in der Regel nur eine der 
Lesarten richtig. Hier benotigen wir einen Mechanismus zur Disambiguierung (WSD, Wortsinndi- 
sambiguierung, vgl. Abschnitt 3.3, S. 35). 



Konzeptuelle Umsetzung Bei einer Eigennamenerkennung ohne WSD wiirden bei Eintragen, 
die in mehreren Listen sind, alle Kategorien vergeben, etwa fiir alle Vorkommen von Bank sowohl 
'Mobel' als auch 'Ort'. Das Resultat dieses Aufbaus ist so ein semantisch annotierter, aber nicht 
disambiguierter Text. 

Eine solche semantische Annotation, die nicht disambiguiert ist, ermoglicht bei der Extraktion 
einen Recall von 100%, da die richtige Bedeutung in jedem Fall enthalten ist. Dass die Precision 
durch ambige Worter reduziert ist, kann bei einer Verarbeitung der Annotationen durch Menschen 
unproblematisch sein. Fiir eine maschinelle Weiterverarbeitung allerdings ist eine Disambiguierung 
notig (vgl. Abschnitt 3.2.2, S. 34). Ein WSD-Verfahren miisste hier als nachgelagerte Komponente 
die ambigen Annotationen disambiguieren. In einem solchen Szenario sind die moglichen Klassen 



44 In diesem Sinn ist die spater modellierte Wortsinndisambiguierung (WSD) eigentlich eine Eigennamendisambi- 
guierung, da abhangig davon, was als Sinneinheit annotiert wurde, einzelne Worter, Wortgruppen oder Wortteile 
disambiguiert werden konnen. 

45 Auf Wortlisten basiert etwa ANNIE, die Informationsextraktionskomponente von GATE (http://www.gate. 
ac .uk/ie/ annie . html ) 
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der WSD die tatsachlich vergebenen Kategorien der Informationsextraktion. Die WSD ist so ihrer 
Natur entsprechend komplett eingebettet in ihren Anwendungsfall der Informationsextraktion und 
verwendet keine fur den konkreten Anwendungsfall arbitraren Eintrage aus einem Lexikon. 

3.1.2. Umsetzung in TM2 

Als einfuhrendes Beispiel zur Anwendung der in Kapitel [2] beschriebenen Werkzeuge wird in den 
folgenden Abschnitten die Umsetzung einer einfachen Informationsextraktion mit TM2 beschrie- 
ben. 

Agentenmodellierung Basierend auf der bschriebenen konzeptuellen Darstellung der IE konn- 
te ein entsprechender Aufbau in TM2 durch drei Agenten implementiert werden: einem Korpus, 
einem Tokenizer (als Praprozessor) und einem Gazetteer (zur Informationsextraktion). Der Toke- 
nizer verarbeitet den Text des Korpus zu Token und kann in Scala etwa mit folgender Signatur 
implementiert werden: 

|| class Tokenizer extends Agent [String , Token] 

Darauf aufbauend verarbeitet der Gazetteer die Token zu Bedeutungen: 

|| class Gazetteer extends Agent [Token , Sense] 



Grundlegender Aufbau Unter der Verwendung solcher Agenten konnte eine einfache Informati- 
onsextraktion (inklusive Implementierung der Agenten) wie in Listing [5} S. 31 umgesetzt werden. 
Bei einem Export des Experiments enthalt die generierte Dokumentation die Darstellung in Ab- 
bildung[9j S. [31} 



Ein entsprechendes Experiment inklusive Evaluierung konnte wie in Listing [6j S. 32 definiert und 
ausgefuhrt werden (hier ohne Implementierung der Agenten). Die Evaluierung erfolgt hier nicht 
gegen einen echten Goldstandard sondern gegen den Gazetteer selbst ( Gold ist eine Subklasse von 
Gazetteer) . Dies soli die Modellierung mit TM2 einfiihren und die generische Natur der Umsetzung 
unterstreichen: Der Goldstandard kann ein Agent wie jeder andere sein, er muss nur so typisiert 
sein, dass er die gleichen Ausgabedaten produziert wie der zu evaluierende Agent, vgl. Evaluierung 
echter Experimente in den Abschnitten 3.3.4, S. 36 und 3.4, S. 39 Auch hier enthalt die fiir ein 
solches Experiment generierte Dokumentation eine graphische Ubersicht des Experiments (s. Abb. 
10 S. 32). Details zur Implementierung der beteiligten Agenten finden sich in Anhang A. 3.1 S. 

m 



Suche in Ergebnissen In den Ergebnissen der Experimente kann iiber die API nach bestimmten 
Annotationen gesucht werden, etwa nach alien Annotationen des Gazetteer, der die IE durchgefiihrt 
hat: 

|| val result = experiment list gazetteer . getClass 

Wie zuvor fiir API, GUI und DSL allgemein beschrieben, kann die Suche dabei in Annotationen 
eines bestimmten Agenten erfolgen, und Ergebnisse eines anderen Agenten fiir den gleichen Bereich 
zuriickgeben, hier etwa die Token zu Elementen, die vom Gazetteer als NAME annotiert wurden: 

|| val result = experiment find (Sense. NAME, gazetteer . getClass ) by tokenizer . getClass 
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object FullSimple extends Application { 

/* Tokenizer , ein Agent [String , Token] : */ 

case class Token ( f orm : String) extends Comparable [Token] with Serializable { 
def compareTo ( that : Token) = this . form . compareTo ( that . f orm ) 

} 

class Tokenizer extends Agent [String , Token] { 

def process (t: j ava . ut i 1 . Li st [ Annot at i on [Str ing ] ] ) : j ava . util . List [Annotation [Token] ] = 
("\\p{L}+".r findAHIn t . get (0) . getValue () ) . matchData . map ( (m : Match) => 
Annotations . create [Token] ( 

classOf [Tokenizer] , Token (m . mat ched ) , m. start, m. end) ) 

} 

/* Gazetteer, ein Agent [Token , Sense]: */ 

case class Sense (form: String) extends Comparable [Sense] with Serializable { 
def compareTo ( that : Sense) = this . form . compareTo ( that . f orm ) 

} 

class Gazetteer extends Abstract Agent [Token , Sense] { 
def process (t: Token): Sense = { 

val prop = new Pr opert i e s ( ) ; prop . load (new F i 1 e Input St ream (" f i le s / di ctO . proper t ie s ") ) 
Sense(prop.getOrElse(t.form, "")) 

} 

} 

/* Beteiligte Agenten und Experiment: */ 

val (c, t, g) : ( Agent [Str ing , String], Agent [String , Token], Agent [Token , Sense]) = 

(new Corpus, new Tokenizer, new Gazetteer) 
val x = c -> t I t -> g ! 

/* Exeplarische Suche in den Ergebnissen: */ 

println(x find t); println(x find g) ; println(x find ( Sense (" det ") , g) by t)) 



Listing 5: Ein einfaches Experiment zur Informationsextraktion mit TM2 in Scala, inklusive 
Implementierung von Tokenizer und Gazetteer 



TM2-Experiment: 




Corpus 






String 




Tokenizer 






Token 




Gazetteer 









Abbildung 9: Generiertes Diagramm fur Experiment in Listing |5j mit optionaler Ausgabe der 
ausgetauschten Typen 
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val corpus = new Corpus 
val tokenizer = new Tokenizer 
val gazetteer = new Gazetteer 
val gold = new Gold 

val evaluation = new S impl eEvaluat ion [ Sense ] 

val experiment = 

corpus -> tokenizer I 

tokenizer -> (gazetteer, gold) I 

(gazetteer, gold) -> evaluation ! 



Listing 6: Ein einfaches Experiment zur Informationsextraktion, inklusive Evaluierung 



TM2-Experiment: 




Result: 
f: 1,00 (p: l,00,r: 1,00) 



Abbildung 10: Generiertes Diagramm fur Experiment in Listing |6j mit optionaler Ausgabe der 
ausgetauschten Typen 
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Experimentserien Eine Definition mehrerer, unterschiedlich konfigurierter Experimente fur einen 



solchen Aufbau ist wie in Abschnitt 2.4.2, S. 26 beschrieben moglich (s. speziell ListingHl S. 27, vgl. 



allgemeine Form der Experimentserien in Abb. |7| S. 26). Die Ergebnisse der einzelnen Aufbauten 
werden in der generierten Dokumentation tabellarisch aufbereitet, urn eine einfache Analyse der 
Ergebnisse zu ermoglichen (vgl. komplette Experimentserie zur WSD in Abschnitt 3.4, S. 39). 



Auf diese Weise kann etwa beim Entwickeln neuer Verfahren zur IE laufend kontrolliert werden, 
ob und wie Veranderungen der Agentenkonfigurationen die Ergebnisse beeinflussen, etwa wie sich 
komplexe Tokenisierungsalgorithmen oder die Verwendung unterschiedlicher Korpora auswirken. 
Dies ermoglicht eine Art testgetriebener Entwicklung (Beck 2003) von Text-Mining- Komponenten 
und -Verfahren. 



3.2. Wortsinndisambiguierung durch Kontextabstraktion 



Das einfuhrende Beispiel zur Informationsextraktion in Abschnitt 3.1 S. 28 zeigt die grundle- 
gende Verwendung des TM2-Frameworks und stellt zugleich die Bedeutung der Disambiguierung 
fur die Entwicklung von Verfahren der maschinellen Sprachverarbeitung dar: ohne Disambiguie- 
rung ist etwa eine prazise Informationsextraktion nicht moglich. Dies gilt ebenso fur andere An- 
wendungsfalle, z.B. maschinelle Ubersetzung. Zur Vorbereitung der vollstandigen Evaluierung der 



TM2-Werkzeuge durch ihre Anwendung in Abschnitt 3.3, S. 35 ftihren die folgenden Abschnitte 
zunachst in die Domane der Wortsinndisambiguierung durch maschinelles Lernen und die sich aus 
diesem Anwendungsbereich ergebenden Ziele und Anforderungen fur die Experimente ein. Dazu 
werden eigene Vorarbeiten (Steeg 2007) aufgegriffen, erweitert und durch die Implementierung in 
TM2 konzeptuell verallgemeinert (vgl. abschlieBende Darstellung in Kapitel[4j S. 42). 



3.2.1. Motivation und Uberblick 

Mehrdeutige Worter sind Teil der menschlichen Sprache und seit Beginn der Schriftkultur belegt 
(Haarmann 1991:153). Wortsinndisambiguierung (WSD, engl. word sense disambiguation), der 
Prozess der Auflosung der Mehrdeutigkeit eines Wortes anhand seines Kontextes, fallt Menschen 
leicht; maschinell ist dieser Prozess jedoch bislang nicht in vergleichbarer Form durchfuhrbar. Dies 
ist ein wesentlicher Grund dafiir, dass Computer Sprache nicht verstehen konnen und macht so die 
WSD zu einem Kernproblem der Computerlinguistik. 

Der Mensch abstrahiert beim kognitiven Prozess der WSD von den konkreten Kontexten der 
ambigen Worter, vermutlich auf Grundlage eines "einheitlichen Modus [...] der Informationsver- 
arbeitung" (Singer 2002:145), mit dem Daten unterschiedlicher Herkunft (d.h. die verschiedenen 
Sinneswahrnehmungen) verarbeitet werden. Diese Verbindung aus domanenspezifischen Daten, die 
mit einem domaneniibergreifenden Mechanismus verarbeitet werden, entspricht Prinzipien des ma- 
schinellen Lernens, dessen Datenbasis in der Sprachverarbeitung Korpora bilden (vgl. Abschnitte 
j~2~T] S.§. 



Diese Konzepte werden im Folgenden zur Evaluierung des TM2-Frameworks mit verschiedenen 
Klassifikationsverfahren und Daten des British National Corpus (BNC) zur WSD umgesetzt (s. 



Abschnitt 3.4, S. 39). Die modulare Umsetzung der WSD im TM2- Framework macht das WSD- 
Verfahren fiir unterschiedliche Anwendungen in der maschinellen Sprachverarbeitung zuganglich. 
Sie eroffnet zudem zahlreiche Moglichkeiten zur Reproduktion und Weiterentwicklung des Verfah- 
rens selbst sowie dariiber hinaus, etwa durch die Nutzung einzelner Bestandteile des Verfahrens in 
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anderen Zusammenhangen (vgl. Abschnitt 4.1, S. 42). 



3.2.2. Wortsinndisambiguierung 

Definition und Einfuhrung Wortsinndisambiguierung ist eine kognitive Leistung bei der men- 
schlichen Sprachverarbeitung und ein zentrales Problem der Computerlinguistik. Gegenstand der 
WSD ist die Auswahl der im Kontext passenden Lesart mehrdeutiger Worter (Agirre & Edmonds 
2006b), etwa in Hast du die neue Bank gesehen? die zu aktivierende Lesart von Bank, z.B. als 
'MobeP oder als 'Ort'. 

WSD ist eine Voraussetzung fur verschiedene Aufgaben der maschinellen Sprachverarbeitung 46 . 
WSD ist fiir Menschen in der Regel 47 einfach, fur Computer aber bislang, insbesondere fur Polyse- 
mie, nicht vollstandig moglich. Aufgrund seiner Abhangigkeit von verschiedenen kognitiven Leis- 
tungen wie logischem Denken und Weltwissen (Ide & Veronis 1998:2, Agirre & Edmonds 2006b:l) 
kann WSD als kognitives Problem charakterisiert werden. Auf Grundlage einer Vorstellung von 
Wortsinn als Kontextabstraktion soil in den folgenden Abschnitten das TM2-Framework zur Um- 
setzung eines Verfahrens zur WSD verwendet und so evaluiert werden. 

Forschungsstand der WSD Durch die Arbeit von Lexikographen und durch die Digitalisierung 
von Lexika (vgl. Wilks et al. 1996 :vii) stehen vielfaltige Ressourcen fiir die maschinelle Sprachver- 
arbeitung zur Verfugung, in denen die Bedeutung eines Wortes auf Grundlage der Entscheidungen 
von Lexikographen enthalten ist. Die Arbeitshypothese in der maschinellen Sprachverarbeitung 
und speziell der WSD, lautete daher fiir den Bereich der Bedeutung lange: Bedeutung ist das, was 
im Lexikon steht. Dies fiihrt jedoch zu verschiedenen Problemen, die in der WSD-Community aus 
pragmatischen Griinden 48 lange ignoriert wurden (Agirre & Edmonds 2006a:9, vgl. Kilgarriff 2006). 
Die allgemeine Gultigkeit von Verfahren und der Wert von Erkenntnissen auf Basis bestimmter 
Lexika ist aber fragwiirdig, da z.B. unterschiedliche Anwendungen der WSD eine unterschiedliche 



Granularitat der moglichen Bedeutungen erfordern (Ide & Wilks 2006:58), vgl. Abschnitt 3.1, S. 



Unterschiedliche Verfahren zur isolierten WSD sind inzwischen ausfuhrlich beschrieben (Wilks 
et al. 1996; Ide & Veronis 1998; Manning & Schtitze 1999; Stevenson 2003; Agirre & Edmonds 
2006a). Forschungsbedarf besteht dagegen allgemein im Bereich der Integration mit der eigentli- 
chen Anwendung: entsprechend seiner Natur als Mittel sollte WSD im Kontext einer konkreten 
Anwendung evaluiert werden, was bisher jedoch kaum geschieht (Stevenson 2003; Agirre & Ed- 
monds 2006a). 

Die maschinelle Disambiguierung von Homonymie ist erheblich einfacher als die von Polysemie. 
So wird automatische WSD fiir Homonymie mit Ergebnissen iiber 95% schon bei kleinen Trai- 



46 z.B. bei der maschinellen Ubersetzung: wenn etwa ein MU- System in einem englischen Text auf das Wort bank 
trifft, so muss dies je nach Lesart etwa im Deutschen als Bank oder als Ufer iibersetzt werden - oder bei 
der Informationsextraktion: werden etwa in englischen Texten Begriffe des Finanzwesens gesucht, sollte eine 
Fundstelle von bank je nach Lesart ausgewahlt oder iiber gangen werden. 

47 Eine Vielzahl von Witzen basiert auf falsch oder nicht aufgeloster Ambiguitat, z.B.: Treffen sich zwei Jager. - 
Beide tot. 

48 Die Natur des WSD-Problems erfordert ein Bedeutungsinventar, aus dem die passende Bedeutung ausgewahlt 



wird (vgl. Abschnitt 3.1 S. 28 1 
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ningsinputs als gelostes Problem angesehen 49 (Agirre & Edmonds 2006a: 14). WSD ftir Polysemie 
ist dagegen deutlich schwieriger, da eine Abgrenzung der polysemen Lesarten haufig nicht einfach 
ist (je nach Korpus Leistungen von 60-70%, vgl. Agirre Sz Edmonds 2006a:14); dies gilt dabei nicht 
nur fur maschinelle Verfahren, sondern auch fiir die menschliche Leistung: so betragt etwa die 
Ubereinstimmung der menschlichen Annotatoren (inter- annotator agreement, ITA) fiir die Daten 
des English Lexical Sample Task im Rahmen von Senseval-3 (s. Abschnitt |3.4 S. 39) lediglich 
67,3% (Mihalcea et al. 2004; Agirre & Edmonds 2006a:14). 



3.3. Typsichere Model lierung von maschinellem Lernen 

Im Folgenden wird eine Umsetzung von maschinellem Lernen zur WSD mit TM2 beschrieben. 



3.3.1. Merkmalsberechnung 

Als Beispielagenten zur Evaluierung des TM2-Frameworks werden Verfahren zur Kontextrepra- 
sentation aus eigenen Vorarbeiten (Steeg 2007) gegeneinander evaluiert: die Worter, Wortlangen, 
sowie buchstabenbasierten Tri- und Heptagramme (7-Gramme) im Kontext der Zielworter. Die 
drei dargestellten Verfahren zur Merkmalsberechnung haben nicht den Anspruch, praxistaugliche 
Algorithmen zur numerischen Merkmalsreprasentation zu sein, sondern stellen im Sinne eines Tu- 
torials einfache exemplarische Uberlegungen und Fragestellungen dar, mit denen die Verwendung 
des TM2-Frameworks demonstriert werden soil. 

Konzeptuell wird bei all diesen Verfahren der Kontext eines Tokens mit einem einzigen Merk- 
malsvektor dargestellt, dessen Merkmale auf den Wortern oder buchstabenbasierten N-Grammen 
der Worter im Kontext des Zielwortes basieren. Alternative Reprasentationen waren etwa die Ver- 
wendung eigener Vektoren fiir jedes Wort im Kontext, die zusammengenommen die Merkmale des 
Zielwortes darstellen konnten. Solche Verfahren konnten als zusatzliche Agenten implementiert und 
in den dargestellen Experimenten evaluiert werden. 



3.3.2. Agentenmodellierung 

Die verschiedenen Verfahren zur Merkmalsberechnung konnen in TM2 (unter Verwendung der 
beschriebenen standardisierten Darstellung von Merkmalen als numerische Vektoren) als einzi- 
ger Agent implementiert werden, dem bei der Intanziierung ein Konfigurationsstring mit dem zu 
verwendenden Verfahren iibergeben wird ("word", "length", "3-gram", etc.), z.B. new Features ("3-gram") fiir 
Trigramme. Ein solcher Agent erzeugt Merkmalsvektoren fiir Kontexte: 

| class Features implements Agent < Context , FeatureVector > 

Der context liefert dabei die darzustellenden Daten, ein FeatureVector enthalt die erzeugten nume- 
rischen Werte in einer List<Fioat>. Details zur Imp lenient ierung der Agenten finden sich in Anhang 
A~4~2l S.[60l 



49 Eine solche Aussage, dass WSD fiir Homonymic gclost sci (Agirre & Edmonds 2006a 14), heifit dabei im Grundc 
aber, dass WSD bisher nur fiir die einfachsten Falle von Mehrdeutigkeit funktioniert . 
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3.3.3. Integration bestehender Klassifikatoren: Weka 



Weka 50 enthalt eine groBe Menge wohldokumentierter Umsetzungen von etablierten und expe- 
rimentellen Klassifikationsalgorithmen in Java. Es bietet damit eine wertvolle Ressource fiir die 
Umsetzung von Text-Mining- Experimenten allgemein, und speziell zur Klassifikation in TM2. 

Weka- Klassifikatoren Weka-Klassifikatoren (z.B. weka. classifiers .bayes .NaiveBayes ) erben von einer 
gemeinsamen Superklasse ( weka. classifiers . Classifier ). Durch die Aggregation eines solchen Weka- 
Klassifikators lasst sich ein Weka- Wrapper generisch implementieren: der Wrapper wird mit der 
konkreten Instanz eines Weka-Klassifikators erzeugt - z.B. new WekaWrapper (new NaiveBayes) - und dele- 
giert die eigentliche Klassifikation an diesen, vgl. Bloch (2008:81), Gamma et al. (1995:20). Details 



zur Implementierung 51 der Weka- Integration linden sich in Anhang A.4 S. 60 Implementiert ein 
solcher Wrapper zudem das A/eni-Interface, ist das eigentliche Klassifikationsverfahren ein Kon- 
figurationsdetail eines Agenten und kann ausgetauscht und gegen Alternativen evaluiert werden 



(vgl. Experimente in Abschnitt 3.4, S. 39) 



Agentenmodellierung In Begriffen der TM2-API kann maschinelles Lernen mit den beschrie- 
benen Agenten fiir Merkmalsberechnung und Klassifikation als Kombination aus Analyse und 
Synthese modelliert werden: Beim Training wird in einer Synthese von Merkmalen und Bedeutung 
ein Modell gebildet, das die spatere Klassifikation ermoglicht ( ModeKFeatureVector , Sense> ). Bei der 
Klassifikation analysiert der Klassifikator Merkmale eines Agent<?, FeatureVector> (vgl. beschriebene 
Agentenmodellierung fiir die Merkmalsberechnung) und ermittelt daraus Bedeutungen, d.h. er ist 
em Agent <FeatureVector, Sense>. Fiir den Wrapper ergibt sich damit in Java folgende Typsignatur: 

| class WekaWrapper implements Agent <FeatureVector , Sense>, ModeKFeatureVector , Sense> 

Die entsprechende Signatur in Scala beschreibt die modellierte Funktion noch treffender: 

j class WekaWrapper extends Agent [FeatureVector , Sense] with Model [FeatureVector , Sense] 



So kann der Weka- Wrapper in Analysen und Synthesen (vgl. Abschnitt 2.3.2, S. 14) mit anderen 



Agenten zur Durchfiihrung von Experimenten verwendet werden (vgl. Experimente in Abschnitt 



3.4, S. 39). 



3.3.4. WSD mit Pseudoambiguitat 

Ein einfaches Mittel zur Evaluierung von WSD-Systemen ist automatisch generierte Ambiguitat 
in Form sogenannter Pseudoworter. Dabei wird jedes Auftreten von zwei Wortformen der gleichen 
Wortart durch eine Zusammensetzung der Worter ersetzt (etwa alle Vorkommen von banana und 



50 Weka Machine Learning Project, http : / / www . cs . waika to . ac . n z/~m l/ 

51 Wie bestimmte Teile von Experimenten (vgl. Abschnitt 



2.3.4 



/gl. Witten & Frank (2000) 



17 1 konnen auch Training und Klassifikation 



ohnc gemeinsamen Zustand und so konzcptucll cinfach ncbcnlaufig implementiert werden, indem die Klassifikato- 
ren fur die unterschiedlichen Kategorien (bei der WSD etwa die ambigen Lemmata, z.B. Bank) getrennt trainiert 
und verwendet werden. So konnen alle untersuchten Lemmata parallel verarbeitet werden. Das in Abschnitt |3.4| 
(S. 39 1 verwendete Korpus etwa enthalt 57 ambige Lemmata, wodurch hier bei Training und Disambiguierung 
57 separate Threads gestartet werden konnten. Im gleichen Mafie, in dem bei einem Anstieg der verwendeten 
Lemmata der Aufwand fiir Training und Disambiguierung zunehmen wiirde, wiirde so automatisch zunehmend 
parallele Rechenleistung nutzbar gemacht. 
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class Ambig extends Pseudo Amb ig ( " and " , "the") 
class Gold extends PseudoAmbig ( " and " , "the") 

val (corpus, ambiguity, gold, tokenizer , evaluation) = 

(new Corpus, new Ambig, new Gold, new Tokenizer, new S impl eEvaluat i on ) 

val (features, classifier) = 

(new Features ( "3-gram") , new Class if ier ( new SMO)) 

val x = 

/* Vorver arbe itung : */ 

corpus -> tokenizer I tokenizer -> ambiguity I 

/* Trainingsmerkmale : */ 

(tokenizer, ambiguity) -> features I 

/* Testmerkmale : */ 

ambiguity -> features I 

/* Training des Klassif ikators : */ 

(features, ambiguity) -> classifier I 

/* Klas s if ikat ion : */ 

features -> classifier I 

/* Evaluierung : */ 

tokenizer -> gold I (classifier, gold) -> evaluation ! 



Listing 7: WSD-Experiment mit Pseudoambiguitat 



door durch banana- door). Die korrekten Lesarten sind so durch die Ursprungsform gegeben (z.B. 
banana oder door), vgl. Manning & Schiitze 1999:233. 

Gegen eine Evaluierung auf dieser Grundlage spricht, dass es sich bei Pseudowortern um kein 
echtes sprachliches Phanomen handelt und daher gute Ergebnisse nur bedingt Ruckschliisse auf 
Phanomene der lexikalischen Semantik erlauben. So entsprechen Pseudoworter etwa nie Polysemie, 
sondern stets eher Homonymie (Palmer et al. 2006:86). Das heifit im Zusammenhang mit der in 



Abschnitt 3J2 S. 33 dargestellten Vorstellung von Wortsemantik als Kontextabstraktion, dass 
Pseudoambiguitat im Vergleich zu natiirlicher Mehrdeutigkeit zu einfach aufzulosen ist. Daher 
wird Pseudoambiguitat hier nur als Beispiel zur Einfuhrung der Modellierung von WSD mit TM2 



verwendet. Vollstandige Experimente finden sich in der Senseval-Evaluierung in Abschnitt 3.4, S. 



Aufbauend auf die oben zur Agentenmodellierung verwendeten Elemente des TM2-Frameworks 
kann ein einfaches, auf Pseudoambiguitat basierendes WSD-Experiment etwa wie in Listing [7j S. 37 
definiert und ausgefiihrt werden. Durch die Nutzung von Pseudoambiguitat kann die gleiche Klasse 
fur die Bereitstellung von Trainings-, Test- und Goldstandard-Annotationen verwendet werden (im 
Experiment in Form von Subklassen der Klasse ps eudoAmbig ) . 

Die generierte Dokumentation enthalt eine tjbersicht iiber den Aufbau des Experiments, die in 
wiedergegeben ist (vgl. Modellierung eines alternativen WSD-Experiments in 



Abbildung 



Abschnitt 3.4 



11 



S. 
S. 
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39). Der von diesem einfiihrenden Experiment verwendete Text und Details zur 



Implementierung der beteiligten Agenten finden sich in Anhang |A.4 , S. 60 



3.3.5. Mogliche Experimente und Fragestellungen 

Auf Basis des beschriebenen Grundaufbaus und der dargestellten Implementierungen der Agen- 
ten kann nun durch spezielle Experimente und deren Evaluierung bestimmten Fragestellungen 
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TM 2 -Experiment: 



Corpus 



Synthesis{Tokenize ■Ambig) 



Ambig 



Sv ntliesi.sf FcMluit"-; Ainln^i' 



Synthesis(f lassifier.Goid) 



SimpleE valuation 



Result: 
f: 0,60 (p: 0.60. r: 0,60) 



Abbildung 11: Fiir WSD- Experiment mit Pseudoambiguitat generiertes Diagramm (durchgezo- 
gene Linien beschreiben Analysen, gestrichelte Linien beschreiben Synthesen) 



nachgegangen werden, etwa der Suche nach optimalen Verfahren zur Merkmalsberechnung oder 
Klassifikation. Diese Moglichkeiten werden im Rest dieses Abschnitts beschrieben. 



Generische Evaluierung durch Annotationsvergleich Bei der dargestellten Evaluierung mit 
Pseudoambiguitat liegen die Ergebnisse und der Goldstandard im gleichen Format vor, sie werden 
im Experiment von zwei Agenten mit einer gemeinsamen Superklasse erzeugt (pseudoAmbig). Dadurch 
kann ein Vergleich auf Basis eines generischen Evaluations- Agenten erfolgen, der unabhangig von 
den konkreten Typen die Werte der Annotationen vergleicht 52 (vgl. im Gegensatz dazu die native 



Senseval- Evaluierung in Abschnitt 3.4, S. 39). Die Evaluierung kann dabei wie die Klassifikation 



als Modell beschrieben werden, das hier in einer Synthese aus dem Ergebnis der WSD und dem 
Goldstandard gebildet wird (siehe Abb. 



11 



S. 38). 



Evaluierung von Verfahren zur Merkmalsberechnung Zur Evaluierung von verschiedenen Ver- 
fahren zur Merkmalsberechnung kann auf Basis des oben dargestellten Aufbaus eine Experiment- 
serie formuliert werden. Dabei wiirden die unterschiedlich konfigurierten Agenten zur Merkmals- 
berechnung etwa folgendermafien deklariert: 



f or { // ... 

impl <- Li st ( " 3- gr am " , "7-gram 1 
feat = new Features ( impl , 4) 

}//... 



1 word " , " length " ) 



52 Die Typen von TM2-Annotationen miissen das Java-Interface Comparable implementieren und haben so einen 
einheitlichen Vergleichsmechanismus, der etwa fiir eine generische Evaluierung (aber auch Sortierung) genutzt 
werden kann. 
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In diesem Beispiel wiirde das Experiment so viermal ausgefiihrt, jeweils mit den vier unter- 
schiedlichen Verfahren zur Merkmalsberechnung (vgl. Grundform fiir Experimentserien in Abb. |7| 



S. 26) 



Evaluierung von Klassifikatoren Analog kann eine Evaluierung verschiedener Klassifikations- 
verfahren umgesetzt werden, etwa unter Verwendung unterschiedlicher Weka-Implementierungen 



(vgl. Abschnitt 3.3.3, S. 36). 



Wie bei der Evaluierung der Merkmalsberechnung konnte hier das Experiment viermal mit un- 
terschiedlichen Klassifikationsalgorithmen ausgefiihrt werden, die (wie oben die Strings zur Spezifi- 
kation der Merkmalsberechnung) als Konfigurationsdetail dem Agenten iibergeben werden konnen: 



f or { // ... 

algo <- List (new BayesNet , new NaiveBayes , new SMO , new HyperPipes) 
clas = new Clas s if ier ( algo ) 
}//... 



Experimentserien und Evaluierung durch Auswertung Ebenso konnen samtliche Variablen in 
einer einzigen Experimentserie formuliert werden, und unterschiedliche Fragestellungen (z.B. nach 
Merkmalsberechnung oder Klassifikation) auf Basis der tabellarisch aufbereiteten Ergebnisse be- 
antwortet werden. Bei einer solchen Reihe waren beide Agenten variabel, und samtliche Permu- 
tationen der Konfigurationen wiirden automatisch ausgefiihrt (hier 4 Verfahren zur Merkmalsbe- 
rechnung und 4 Klassifikatoren, also 4*4=16 Durchlaufe): 

f or { // ... 

impl <- List ( "3-gram" , "7-gram", "word", "length") 

algo <- List (new BayesNet, new NaiveBayes, new SMO, new HyperPipes) 
feat = new Features ( impl , 4) 
clas = new Clas s if ier ( algo ) 
}//... 



Details zur Implementierung dieser einfiihrenden Experimente finden sich in Anhang |A.4[ S. [60 



Eine vollstandige Beschreibung solcher Experimentserien mit Senseval-Daten (und damit auf Basis 



echter Mehrdeutigkeit) findet sich im folgenden Abschnitt 3.4 

3.4. Senseval-Evaluierung 



Der folgende Abschnitt 3.4.1 beschreibt basierend auf eigenen Vorarbeiten (Steeg 2007) die Senseval- 



Workshops und das verwendete Senseval-Korpus. Darauf aufbauend wird ab Abschnitt 3.4.2, S. 41 
die Implementierung einer Senseval-Evaluierung mit TM2 dargestellt. 

3.4.1. Korpora zur Evaluierung 

Mit den Senseval- Workshops 53 existiert eine Reihe von Veranstaltungen, die (nach dem Vorbild der 
Message Understanding Conferences in der Informationsextraktion, s. etwa Grishman & Sundheim 
1996) eine vergleichende Evaluierung von Systemen zur WSD auf der Basis gemeinsamer Korpora 
zum Gegenstand haben (vgl. Palmer et al. 2006:86). Fiir diese Workshops wurden Trainings- und 



53 Evaluation Exercises for the Semantic Analysis of Text, http://www.senseval.org/senseval3 
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Wortarten 


Lemmata 


Lesarten 


Lesarten 






(fein) 


(grob) 


Nomen 


20 


5,8 


4,4 


Verb en 


32 


6,3 


4,6 


Adjektive 


5 


10,2 


9,8 


Gesamt 


57 


6,5 


5,0 



Tabelle 1: Uberblick iiber das Bedeutungsinventar im verwendeten Senseval-Korpus: Wortarten 
der ambigen Lemmata und durchschnittliche Anzahl von Lesarten pro Wort bei feiner 
und grober Kornung (aus: Mihalcea et al. 2004) 



Testkorpora bereitgestellt, fiir die Vergleichswerte wie das inter- annotator agreement (ITA) ver- 
fiigbar sind. Im Folgenden wird die grundsatzliche, zuvor beschriebene Modellierung von WSD mit 
TM2 mit Korpora des english lexical sample task im Rahmen von Senseval-3 (vgl. Mihalcea et al. 
2004) umgesetzt. So soil die praktische Anwendbarkeit des TM2-Frameworks fiir eine komplexe 
computerlinguistische Fragestellung dargestellt werden. 

Die Senseval-Trainingskorpora enthalten ambige Zielworter, die mit ihren korrekten Lesarten 
gekennzeichnet wurden. Die Umsetzung der Senseval-Annotation als Agent macht die verwende- 
ten Senseval-Daten auch fiir andere Experimente zuganglich, die keine anderen der hier genutzten 
Agenten (etwa fiir Merkmalsberechnung und Klassifikation) verwenden, und erschliefit so prinzi- 
piell auch die Senseval-Korpora 54 der anderen tasks 55 fiir solche Experimente. Auf der anderen 
Seite sind neben der WSD auch andere Aufgaben der maschinellen Sprachverarbeitung token- 
bezogene Klassifikationsprobleme, etwa das Auszeichnen von Wortarten (part of speech tagging, 
POS-Tagging). Hier wiirde etwa ein bloBer Austausch des Senseval- Agenten (der das Korpus be- 
reitstellt) gegen ein mit POS-Tags ausgezeichnetes Korpus die Nutzung der eigentlich zur WSD 
implementierten Merkmalsberechnung und Klassifikation zum POS-Tagging ermoglichen. 

Das Senseval-3 Korpus des english lexical task enthalt Ausschnitte des BNC - fiir das Training 
8529 Vorkommen 57 ambiger Lemmata, zur Disambiguierung 5693 Vorkommen. Einen Uberblick 
fiber das Bedeutungsinventar des Korpus gibt Tabelle [TJ S. [40} Die Bedeutungen stammen fiir 



Nomen und Adjektive aus WordNet 1.7.1, fiir Verben aus Wordsmyth (Mihalcea et al. 2004). 

Wie die Bedeutungen nicht-ambiger Worter konnen auch die verschiedenen Lesarten ambiger 
Worter einander konzeptuell fiber- (Hyperonymie) oder untergeordnet (Hyponymie) sein, sowie 
eine gemeinsame, fibergeordnete Bedeutung haben (Kohyponymie). So ist etwa in WordNet 56 bet 
mit der Lesart 'the money risked in a gamble' den weiteren Lesarten 'the initial contribution that 
each player makes to the pot' und 'the combined stakes of the betters' fibergeordnet (vgl. Abb. 



12). 



Bei einer solchen hierarchischen Strukturierung moglicher Bedeutungen konnen bei der Eva- 
luierung drei Stufen von Bedeutungsgranularitat zugrunde gelegt werden: feine (fine), gemischte 



54 Die Daten haben grundsatzlich ein gemeinsames Format und sind so prinzipicll wie hier implcmcnticrt nutzbar. 
Sie sind jedoch z.T. nicht in validem XML (z.B. keine maskierten Sonderzeichen) , sowie manchmal in einer 
einzclnen Datei und manchmal fiir verschiedene Lemmata auf verschiedenc Datcicn vcrteilt. Hier miisste also 
ein Import der verschiedenen Varianten des Formats oder eine Normalisierung der Daten implementiert werden. 

55 Senseval 3 Tasks, http://www.senseval.org/senseval3/tasks.html 

56 WordNet kann unter http://wordnetweb.princeton.edu/perl/webwn online abgefragt werden. 
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bet 7 



ZA 



bet 7.1 



bet 7.2 



Abbildung 12: Hierarchisch stukturierte Lesarten im Senseval-Korpus (Palmer et al. 2006:79) 



[mixed) und grobe 



coarse) 



Kornung (Palmer et al. 2006:79). Bei feiner Kornung sind nur exakte 



Treffer korrekt - so ware etwa bei einer korrekten Lesart 7 in Abbildung 12 die Wahl von 7.1 oder 
7.2 nicht korrekt. Bei grober Kornung dagegen waren sowohl die Wahl von 7, von 7.1 als auch 
von 7.2 korrekt, d.h. Hyponyme, Hyperonyme und Kohyponyme der korrekten Lesart werden auch 
als korrekt gewertet. Bei gemischter Kornung schliefilich zahlen Kohyponyme der korrekten Lesart 
nicht als korrekte Ergebnisse, und fur Hyperonyme wird die Wertung abhangig von der Anzahl 



ihrer Hyponyme proportional verringert. So wiirde z.B., wenn Lesart 7.1 in Abbildung 12, S. 41 
korrekt ware, die Wahl von 7.1 mit 1, die von 7 mit 0.5 und die von 7.2 mit bewertet. 

Die drei Granularitaten konnen als Konfigurationsparameter bei der Modellierung von Experi- 
menten dienen, vergleichbar mit der dargestellten Konfiguration von Merkmalen und Klassifikati- 
onsverfahren (s. Abschnitt 3.4.5, S. 42, vgl. Agirre & Edmonds 2006a:16; Mihalcea et al. 2004). 



3.4.2. Agentenmodellierung 

Ausgangspunkt der Modellierung ist das Korpus, dessen getrennte Aspekte (Kontexte und korrekte 
Lesarten) durch getrennte Agenten implementiert 57 werden konnen. Zum Einen liefern die Korpora 
die Kontext der Zielworter: 

|| class SensevalData (s : String) extends Agent [String , Context] 

Zum Anderen liefern die Korpora Zugriff auf die Zielworter der Kontexte, die beim Training 
disambiguiert werden und bei der Klassifikation ambig sind: 

|| class SensevalSense ( s : String ) extends Agent [Context , Ambiguity] 

Fiir Training und Klassifikation sollen die Kontexte numerisch reprasentiert werden: 

|| class ContextFeatures extends Agent [Context , FeatureVector ] 

Der Klassifikator schliefilich kann als Agent Lesarten fiir Merkmale ermitteln, auf Basis eines 
Modells, das Merkmale auf gelernte Klassen bezieht: 

class SensevalClassif ier 

extends Agent [FeatureVector , Sense] with Model [FeatureVector , Ambiguity] 

57 Fiir eine konsistente Darstellung werden hier nur Scala-Signaturen verwendet, tatsachlich wurden die Agenten 
teils in Scala und Teils in Java implementiert. Die Verwendung von Java- und Scala- Agenten in einem Experiment 
zeigt, wie eng in TM2 Komponenten in Scala und Java kombiniert werden konnen. 
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3.4.3. Native Evaluierung mit dem Senseval-Scorer 



Die Senseval- Workshops verwenden ein eigenes Programm, das die Ergebnisse der verschiedenen 
WSD-Verfahren auswertet und dabei die reichen semantischen Metadaten zur Struktur der Lesar- 
ten des Senseval-Korpus (s.o.) ausnutzt, etwa indem automatisch Ergebnisse fiir die verschiedenen 
Bedeutungsgranularitaten berechnet werden. 

Im Sinne nachvollziehbarer und vergleichbarer Ergebnisse ist es in einem solchen Fall sinnvoll, 
die Ergebnisse tatsachlich von diesem Programm berechnen zu lassen, statt auch hier den gene- 
rischen Vergleichsmechanismus aus der Pseudowort-Evaluierung zu verwenden (etwa indem der 
Senseval-Goldstandard in TM2-Annotationen transformiert wiirde). Die Implementierung eines 
solchen, quasi nativen Evaluationsagenten erfolgt hier durch den internen Aufruf des Senseval- 
Bewertungsprogramms, und einer anschliefienden Verarbeitung der Programmausgabe mit regula- 
ren Ausdriicken (zu Details siehe Hinweise in Anhang A.l, S. 53). 



3.4.4. Modellierung der Experimente 

Die Modellierung der Senseval-WSD in TM2 auf Basis der oben dargestellten Agentenmodellierung 

^ 8 . In Listing p| werden die Typ-Angaben (z.B. Agent [Featurevector, sense]) 



findet sich in Listing 8 S. 43 



weggelassen. Der Scala-Compiler uberpruft dennoch die Typisierung mithilfe von Typ-Inferenz. 
Um die Typisierung explizit zu machen, konnen die Typen wie generell in Scala-Code optional 



hinzugefugt werden (vgl. Listing [9j S. 45 fiir eine vollstandig explizit typisierte Version der Expe- 
rimentserie). 

Die Verwendung der optionalen mn-Methode fiihrt zu einer automatischen parallelen Ausfiihrung 
der Experimente und einer Aufbereitung der unterschiedlichen Ergebnisse (hier fiir 4*4*3=48 Ex- 
perimente). Die generierte Dokumentation der einzelnen Experimente enthalt eine Ubersicht iiber 
den Aufbau des Experiments, die in Abbildung 13, S. 44 wiedergegeben ist (vgl. Implementierung 
der WSD- Experimente mit Pseudoambiguitat in Abschnitt 3.3.4, S. 



36) 



3.4.5. Exemplarische Fragestellungen und Ergebnisse 

Die Ergebnisse der so modellierten und unterschiedlich konfigurierten Experimente werden automa- 



tisch tabellarisch in Form einer HTML-Datei aufbereitet (s. Abb. 14, vgl. konvertierte 59 Darstellung 



in Anhang A.4.3). 



4. Zusammenfassung, Einordnung und Ausblick 
4.1. Typsichere Modellierung im Text-Mining 

In der vorliegenden Arbeit wurden, basierend auf der Zielsetzung einer Vereinfachung der Entwick- 
lung von Software fiir Text-Mining, Werkzeuge zur typsicheren Modellierung von Experimenten im 
Text-Mining entwickelt (Kapitel|2j S.[9]). Zur Evaluierung der Werkzeuge durch eine exemplarische 

58 Im Gegensatz zum Experiment mit Pseudoambiguitat weiter oben werden hier Scalas singleton objects verwendet, 
wodurch fiir Agenten, von denen in alien Experimenten nur eine Instanz benotigt wird, eine Erzeugung mit new 
unnotig wird. 

59 Die generierte HTML-Dokumentation wurdc mithilfe des Programms html2latex (http: //htmltolatex. 
sourceforge.net/) fiir die Darstellung in dieser Arbeit konvertiert. 
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object trainData extends SensevalData (" EnglishLS . train . xml " ) 
object testData extends SensevalData (" EnglishLS . test . xml " ) 
object trainSense extends S ensevalSens e (" Engl i shLS . train . xml " ) 
object corpus extends Corpus 

class TrainFeatures extends Features; class TestFeatures extends Features 
run { 

/* Variable Konf igur at i on in den unterschiedlichen Durchlaeuf en : */ 
for { 

algo <- List (new NaiveBayes , new BayesNet , new SMO , new HyperPipes) 

feat <- List (" 3-gram " , "7-gram", "word", "length") 

eval <- List (" fine " , "mixed", "coarse") 

classifier = new Sens evalClas s if i er ( algo ) 

trainFeat = new Tr ainFeatur es ( f eat ) 

testFeat = new Te st Feature s ( f eat ) 

evaluation = new SensevalEval ( eval ) 

} 

/* Festes Zusammenspiel der unterschiedlich konf igur ierten Agenten: */ 
yield { 

/* Vorverarbeitung : */ 

corpus -> (trainData, trainSense) I 

/ * Training : */ 

trainData -> (trainFeat , trainSense) I 

(trainFeat, trainSense) -> classifier I 

/* Klas s i f ikat i on : */ 

testData -> testFeat I 

testFeat -> classifier I 

/* Evaluierung: */ 

classifier -> evaluation 

} 

} 



Listing 8: WSD-Experiment mit Senseval-Daten, vgl. Abb. 13, S. 44 
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TM2-Experiment: 



Corpu 



TrainData 



Synthesi.s(Tra>frreature.s,Traii Sense) 



TrainSense 



TrainFeatures 



SensevalClassifier 



TestFeatures 



EvalSense 




Abbildung 13: Generiertes Diagramm fiir WSD-Experiment in Listing 8l S. 43 
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Abbildung 14: Generierte Ubersicht der Ergebnisse fiir Listing 8l S 
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class TrainData extends SensevalData (" EnglishLS . train . xml " ) 

class TestData extends SensevalData (" EnglishLS . test . xml " ) 

class TrainSense extends SensevalSense (" EnglishLS . train . xml " ) 

class TrainFeatures ( s : String) extends Cont ext Feat ur e s ( s ) 

class TestFeatures (s : String) extends Cont ext Feat ure s ( s ) 

run { 
for { 

/* Konf igur at i onen : */ 

algo : veka . classifiers . Classifier <- List(new NaiveBayes , new BayesNet , new SMO) 
feat: String <- Li st ( " 3- gr am " , "7-gram", "word", "length") 
grain: String <- List (" fine " , "mixed", "coarse") 

/ * Agenten : */ 

corpus : Agent [String , String] = new Corpus 

trainData: Agent [String , Context] = new TrainData 

testData: Agent [String , Context] = new TestData 

trainSense : Agent [Context , Ambiguity] = new TrainSense 

trainFeat : Agent [Context , FeatureVector ] = new TrainFeatures ( feat ) 

testFeat : Agent [Context , FeatureVector] = new Te st Features ( f eat ) 

classifier = new Sens evalClas s if i er ( algo ) 

c las s if i er Agent : Agent [FeatureVector , Sense] = classifier 
model: Model [FeatureVector , Ambiguity] = classifier 
evaluation: Agent [Sense , String] = new SensevalEval (grain) 

/* Int er akt i onen : */ 

corpusData: Analy s i s [ St r ing] = corpus -> (trainData, testData) 
corpusContext : Analy s i s [Cont ext ] = trainData -> (trainFeat, trainSense) 
trainClass : Synt hes i s [ Feature Vect or , Ambiguity] = (trainFeat, trainSense) -> model 
testContext : Analy s i s [ Cont ext ] = testData -> testFeat 
classify: Analysis [FeatureVector] = testFeat -> class i f i er Agent 
evaluate: Analysis [Sense] = c las s if ier Agent -> evaluation 
} /* Ablauf : */ 

yield corpusData I corpusContext I trainClass I testContext I classify I evaluate 

} 



Listing 9: Explizit typisiertes WSD- Experiment, vgl. Listing [8j S. 43 
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Abbildung 15: Zirkulare Natur des Text-Mining 



Anwendung wurden in Kapitel[3j S. 28 basierend auf einer Vorstellung von Wortsinn als Kontextab- 



straktion Text- Mining- Experimente umgesetzt. Diese basieren auf Konzepten des korpusbasierten 



maschinellen Lernens (s. 3.2, S. 33) und verwenden Daten des BNC zur Evaluierung. 

Die Umsetzbarkeit dieser Konzepte mit dem entwickelten Framework zeigt, dass die formale, 
typsichere Representation von Annotationen und Interaktionen im TM2-Framework zur Modellie- 
rung von Text-Mining-Experimenten verwendet werden kann und so ein nutzliches Werkzeug fur 
die Entwicklung von Verfahren fur besseres Text-Mining ist. 

Wie in Kapitel [3] dargestellt, lassen sich mit TM2 vergleichsweise einfach modulare sprachver- 
arbeitende Komponenten entwickeln, die in komplexen Experimenten miteinander kombiniert und 
gegeneinander evaluiert werden konnen. Diese Modularitat, in Verbindung mit der automatisch 
generierten Dokumentation, maximiert die Wiederverwertbarkeit solcher Komponenten und er- 
leichtert die Integration in andere Umgebungen. So ist die Rolle von TM2 die eines Frameworks 
zur experimentellen Entwicklung von Komponenten, die evaluiert und optimiert werden konnen, 
und dann als wohlgekapselte Elemente in andere Umgebungen integriert werden konnen. Diese 
Umgebungen konnen Aspekte umsetzen, die von TM2 selbst nicht abgedeckt werden, wie verteilte 
Datenpersistenz oder graphische Modellierungswerkzeuge. Zugleich ist denkbar, dass graphische 
Werkzeuge oder Persistenzframeworks intern TM2 als Modellierungsformalismus verwenden. 

4.1.1. Generische Annotation fiir zirkulare Informationsanreicherung 

Ein Grundthema, das sich durch diese Arbeit hindurchzieht, ist die zirkulare Natur des Text- 
Mining: Informationen reichern als Metadaten Daten an, und konnen selbst wieder zur Gewinnung 



neuer Informationen genutzt werden (s. Abb. 15). Dieser Prozess, der ein generisches Prinzip der 



Informationsverarbeitung darstellt, kann mit den beschriebenen Konzepten und Werkzeugen ge- 
nerisch modelliert werden. Dies bietet Ankniipfungspunkte auf verschiedenen Ebenen, etwa unter- 
schiedlichen Anwendungsgebieten (computerlinguistischen und allgemein-informationstechnischen, 



vgl. Abschnitte 4.2.1, S. 48 und 4.2, S.E8J), oder deren Teilbereiche (z.B. Vorverarbeitung, Merk- 
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malsberechnung, Klassifikation, etc.). Diese Grundgedanken werden in den folgenden Abschnitten 
ausgefiihrt. 



4.1.2. Textuelle Modellierung als adaquater Formalismus 

Textuelle und graphische Modellierung Klassische SALEs enthalten meist graphische Elemen- 
te, die eine Modellierung der Experimente vereinfachen sollen. Die grundsatzlichen Ziele einer 
SALE, wie die Entwicklung von sprachverarbeitetenden Softwarekomponenten und die Modellie- 
rung, Durchfuhrung und Evaluierung von Experimenten erfordern jedoch konzeptuell keine GUI. 
Im Gegenteil kann die GUI die Moglichkeiten beschranken, da kein direkter Zugriff auf flexible 
formale Modellierungsmechanismen gegeben ist, sondern nur Funktionen fur den Nutzer zugang- 
lich sind, die explizit iiber die GUI verfiigbar gemacht werden (z.B. die Durchfuhrung mehrerer, 
ahnlicher Experimente, etc.). In der Regel erzeugt die GUI auf Basis der zur Verfugung gestell- 
ten Moglichkeiten intern die formale Representation, meist in Form einer XML-Datei, vgl. etwa 
eigenen Vorarbeiten bei der Modellierung der WSD in Tesla (Steeg 2007 :V). 

Die textuelle Modellierung von Text-Mining-Experimenten mit einer DSL ermoglicht in TM2 
die Entwicklung einfacher und komplexer Experimente und erzeugt aus der textuellen Form gra- 
phische Reprasentationen fur die Dokumentation, statt diese graphischen Reprasentationen als 
Modellierungsschicht zu verwenden. Die DSL kann zugleich durch ihre Typsicherheit wie eine spe- 
zialisierte GUI Fehler schon beim Modellieren abfangen, jedoch auf Grundlage eines generischen, 
erweiterbaren Mechanismus: der typsicheren Annotation und Interaktion. Die in Scala eingebettete 
DSL ist zudem extrem flexibel, da alle Moglichkeiten der Basissprache zur Verfugung stehen. Als 
flexible Losung fur ein komplexes Problem hat die textuelle Modellierung hier Vorteile gegeniiber 
einer graphischen Modellierung (vgl. Green & Petre 1992). Beim beschriebenen DSL-Ansatz kann 
zudem die textuelle Modellierung die Basis fur eine graphische Ebene bilden (als API bei der 



eingebetteten Scala-DSL, vgl. Abschnitt 2.4.2, S. 24) oder dasselbe Schema wie diese verwenden 
(als EMF-Metamodell bei der eigenstandigen Xtext-DSL, vgl. Abschnitt 2.4.1, S. 22). So muss 
eine textuelle Modellierung die graphische Modellierung nicht ausschlieBen, sondern sollte je nach 
Implementierung als eine zugrunde liegende oder komplementare Ebene betrachtet werden. 

Typsichere textuelle Modellierung Die Implementierung einer formalen Text-Mining-Notation 



als eingebettete DSL in einer statisch typisierten Basissprache (vgl. Abschnitt 2.4, S. 21) ermog- 
licht Typsicherheit und die Verwendung von weitergehenden Sprachfeatures der Basissprache. Diese 
Verbindung macht eingebettete, typsichere DSLs in Scala zu einer sehr interessanten Moglichkeit 
zur Implementierung von DSLs. Eine Scala-DSL kann zudem auf bestehende Java- APIs aufsetzen 
und diese mittels implicits in veranderter Form zuganglich machen, ohne dass die Java-APIs selbst 
angepasst werden miissen. Eine solche Losung ist damit nicht nur theoretisch oder im experimen- 
tellen Rahmen interessant, sondern eine realistische, praxistaugliche Perspektive fur eine Vielzahl 
von Java-basierten Softwaresystemen. 

Die Verwendung von generischen Datentypen in Agenten, Analysen, Synthesen und Modellen 



(vgl. Abschnitt 2.3 S. 12) ermoglicht die Entwicklung neuer Abstraktionen, die von den Agenten 
in den Experimenten verwendet werden 60 . So kann prinzipiell auf alien konzeptuellen Ebenen von 
strings, iiber Tokens, zu words oder senses modelliert werden. Ein Tokenizer konnte etwa als Agent [string, 
Token] modelliert werden, ein Indexer als Agent [Token, Type], oder ein POS-Tagger als Agent [Token, pos]. 

60 Dieser Ansatz entspricht so dem generellen Ziel von Scala (A Scalable Language, vgl. Odersky et al. 2008:3) 
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Die Datenabstraktion ist dabei ein Implementierungsdetail, das in konkreten Agenten ganz unter- 
schiedlich typsiert werden kann, etwa um spezielle Anforderungen oder neue Ideen umzusetzen. 
Dies macht die Verwendung einer typsicheren DSL zu einem formal strikten, aber zugleich seman- 
tisch reichem und flexiblem Werkzeug fiir die Modellierung von Text-Mining-Experimenten. 

4.2. Ein generelles Modell der Informationsverarbeitung 
4.2.1. Konzeptuelle Parallelen zu Binardaten 

Die konzeptuelle Einfachheit des Annotationsmodells und die Verwendung von XML als Export- 
format fiir die produzierten Annotationen erlaubt eine vielfaltige weitere Nutzung der TM2- 
Ergebnisse. Als Beispiel soil dazu im Folgenden dargestellt werden, wie in TM2-Experimenten 
gewonnene Daten in das im Planets-Projekt entwickelte XCDL-Format exportiert und so einer 
Evaluation mit dem XCL-Comparator zuganglich gemacht werden konnen. 

Datenmigration, Annotation und Evaluierung Im Rahmen des EU-geforderten Planets-Pro- 
jekts 61 wurden unter anderem Werkzeuge zum Vergleich von Binardaten entwickelt (XCL: exten- 
sible characterisation languages, s. Thaller 2009b). 

Binardaten stellen konzeptuell wie textuelle Annotationen eine inhaltliche Auszeichnung von 
Daten dar. Ein Datenformat ist dabei die Definition von Bereichen in den Daten, die unterschied- 
lichen Zwecken dienen, gewissermaBen ein Tagset oder Schema fiir die Annotationen. So kann eine 
konventionelle, nicht-formale Formatspezifikation (z.B. die PNG-Spezifikation 62 ) in einer forma- 
len XML-Reprasentation wie der XCEL (vgl. Schnasse et al. 2009) beschrieben werden. Instanzen 
dieses Schemas oder Formats (z.B. konkrete PNG-Dateien) stellen die annotierten Daten dar, und 
konnen ebenfalls in einer rein textuellen XML-Reprasentation dargestellt werden (der XCDL, vgl. 
Beyl et al. 2009). Die Erzeugung dieser textuellen Instanz-Reprasentationen von konkreten Dateien 
(in der XCDL) kann mithilfe des formalen Schemas (der XCEL) automatisiert werden (Heydegger 
et al. 2009). Dateien, fiir die eine solche XCDL-Reprasentation extrahiert wurde, konnen mithilfe 
des XCL-Comparators automatisch und unter Verwendung verschiedenener Metriken miteinander 
verglichen werden (s. Heydegger et al. 2009:174). So kann etwa die Giite einer Datenmigration 
(z.B. von JPEG zu PNG) evaluiert werden, indem die Ausgangs-XCDL (aus der JPEG-Datei ex- 
trahiert) mit der Ergebnis-XCDL (aus der PNG-Datei extrahiert) verglichen wird (vgl. Schnasse 
et al. 2009). 

Aufgrund der konzeptuellen Nahe von TM2 und XCL lassen sich die von den TM2-Werkzeugen 
erzeugten Daten grundsatzlich auch mit den XCL-Werkzeugen nutzen, die zum Vergleich von 
Binardateien entwickelt wurden. Dazu miissen die TM2-Exportdaten in das benotigte XCDL- 
Format transformiert werden. 

XCDL-Transformation Da Eingabe- und Ausgabeformat der benotigten Transformation XML- 
Formate sind, bietet sich fiir eine Transformation der TM2-Annotationen in die XCDL die XML- 
basierte Transformationssprache XSLT an. Fiir die Umwandlung reichen im Wesentlichen drei 
XSLT- Templates: Das Haupt-Template transformiert die Ergebnisse eines TM2-Experiments in 

61 PLANETS: Preservation and Long-term Access through NETworked Services, http://www. 
openplanetsf oundation. org/ 

62 PNG specification, http://www.w3.org/TR/PNG/ 
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<xsl: template matcli=" experiment "> 
<xcdl id="0"> 

<object id="ol"> 

<normData type = "text" id= " ndl " ><xsl : value - of sele ct = " @dat a " / ></normDat a > 
<property id="pl" source="raw" cat="descr"> 

<name id="id58">textualAnnotation</name> 

<xsl : apply -templates mode = " valueSet s " /> 
</property > 

<xsl : apply -templates mode =" property Set s " /> 
</obj ect > 
</xcdl > 
</xsl:template> 



Listing 10: Haupt-Template einer XSL-Transformation der TM2-Exportdaten in die XCDL 



<coco > 

<compSet > 

<property id="58" name = " t extual Anno t at ion " > 



<metric 


id = 


101 " 


name = 


valueSet St at _ 1 " 


/> 


<metric 


id = 


102 " 


name = 


valueSetStat_2 " 


/> 


<metric 


id = 


121 " 


name = 


value Set Mat ch_l 


1 /> 


<metric 


id = 


122 " 


name = 


valueSetMatch_2 


1 /> 


<metric 


id = 


253" 


name = 


dataRef Match_3 " 


/> 



</property > 
</ compSet > 
</ coco > 



Listing 11: Beispielkonfiguration fur XCL-Vergleich der exportierten Daten 



eine XCDL mit properties vom Typ textualAnnotation (s. Listing 10, S. 49 ,3 ). Ein zweites Template 
transformiert die /afreZ-Attribute von TM2-Annotationen in value sets der Ziel-XCDL, ein drittes 
Template die Positionsinformationen der TM2-Annotationen in property sets der Ziel-XCDL. Die 
vollstandige Transformation der TM2-Annotationen mithilfe von XSLT findet sich in Anhang 



A.2.14, S. 59 



XCDL-Vergleich Die so generierten XCDL-Dateien (etwa fur das Ergebnis einer Informations- 
extraktion mit TM2 und fur einen Goldstandard) konnen dann mithilfe des XCL- Comparators 
miteinander verglichen werden. Dabei miissen Metriken des XCL-Comparators gewahlt werden, 
die mehrere value sets unterstiitzen (die textuellen Annotationen werden hier als ein property mit 



unterschiedlichen value sets betrachtet), z.B. wie in Listing 11 (zu Details der Konfiguration des 
Vergleichs s. Heydegger et al. 2009:197). 

Integration Im Rahmen des Planets-Projekts wurde zur Integration der XCL-Werkzeuge in das 
Planets Interoperability Framework (King et al. 2009) auch eine Java- API fiir die XCL-Werkzeuge 
entwickelt (Steeg et al. 2009). Auf Basis dieser Java-API kann das Ergebnis eines TM2- Experiments 



63 Fiir diese Experimente enthalten die TM2-Exportdaten keine Referenz auf die annotierten Daten in Form einer 
URL im rfato-Attribut, sondern die Daten selbst. 
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mithilfe der XCL-Werkzeuge komplett iiber Java- APIs verarbeitet werden. Zu Details der proto- 
typischen Implementierung s. Hinweise in Anhang A.l , S. 53 



Generizitat des Annotationsmodells Diese Nutzung der TM2-Exportdaten zeigt nicht nur wie 
vielseitig die Ergebnisse im XML-Format verwendet werden konnen, sondern illustriert zudem wie 
universell das Grundkonzept der Annotation von Daten ist: es ist das grundsatzliche Mittel, mit 
dem Daten angereichert werden, seien sie ursprunglich binar (etwa beim Vergleich von Bilddaten 
mit den XCL- Werkzeugen) , oder von Anfang an textuell, wie im Bereich des Text-Mining. Durch 
die Generizitat des Annotationkonzepts konnen so Werkzeuge und Verfahren fur den Vergleich von 
Binardaten wie Bild- Ton- oder Videomaterial prinzipiell auch fur den Vergleich von linguistischem 
Wissen etwa zu Syntax, Semantik, etc. verwendet werden. Kapitel|4]diskutiert im Anschluss an die 
experimentelle Anwendung von TM2 in Kapitel [3] diese Gemeinsamkeit so unterschiedlicher Daten 



und deren Verarbeitung, vgl. speziell die abschlieBenden Darstellungen in Abschnitt |4.2[ S. [48 
4.2.2. Das Kolner Informationsmodell als konzeptuelle Grundlage 



In Abschnitt |4.2.1[ S.[48]wurden Ergebnisse der mit TM2 formulierten Experimente mit Werkzeu- 
gen verwendet, die im Rahmen des Planets-Projekts zur digitalen Langzeitarchvierung entwickelt 
wurden. Dieses praktische Ergebnis deutet auf eine gemeinsame konzeptuelle Basis der scheinbar 
recht verschiedenen Bereiche der maschinellen Sprachverarbeitung und der Migration und Archi- 
vierung von Binardaten. In der Tat lassen sich weitgehende Parallelen feststellen zwischen den 
beschriebenen Konzepten der typsicheren Annotation und dem zugrunde liegenden Modell der 
Planets- Werkzeuge zur Evaluierung von Datenmigrationen (XCL, vgl. Thaller 2009b). 

Eine Formalisierung der rekursiven Natur der Informationsverarbeitung Die Grundidee so- 
wohl des beschriebenen Ansatzes wie auch der XCL ist, dass Metadaten auch nur Daten sind 
(Thaller 2009a:223). Wie aus Daten und Metadaten dabei Informationen werden, lasst sich auf 
verschiedenen Ebenen beschreiben: z.B. Bits als Daten (01100001), assoziierte Zahlen- ('97') oder 
Zeichenwerte ('a') als Information, oder Zahlen als Daten (97) und ihre Einheit als Information ('97 
Grad Celsius'), etc. Diese Bespiele aus Thaller (2009b) zeigen, dass Daten und Information keine 
getrennten Kategorien sind, sondern Idealtypen an entgegengesetzten Enden eines Kontinuums, 
die durch eine Anreicherung schrittweise ineinander iibergehen (Thaller 2009a:226). 



Dies entspricht der oben dargestellten zirkularen Natur des Text-Mining (Abb. 15, S. 46). So ent- 
spricht etwa die Interpretation von Bits als Datentypen (Zahlen oder Zeichen, konkret in Program- 
miersprachen etwa 'int' oder 'char') einer typsicheren Annotation (Datenbereich x, z.B. 01100001 
ist Information vom Typ y, z.B. 'int'). Diese schrittweise Bildung von Information aus Daten wird 
in Thaller (2009a:224) aufbauend auf Langefors (1995) folgendermafien formalisiert: Information 
(I) ist das Ergebnis einer Interpretation (i) vorhergehender Information (die kontinuierlich aus 
Daten gebildet wird), unter Anwendung eines Vorwissen (S), innerhalb der verfiigbaren Zeit (t): 

I x = i(I x - a ,S(I x -p,t),t) (1) 

Die Implementierung von TM2 entspricht diesem Konzept nicht nur prinzipiell durch die generel- 
le Natur von Metadaten- Annotationen, sondern auch in der formalen Modellierung von Agentenin- 
teraktionen. So ist das Grundkonzept der TM2-API, dass Annotationen eines bestimmten Typs in 
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Annotationen eines anderen Typs verarbeitet werden und so schrittweise Information gesammelt 
oder angereichert wird (das Vorwissen S ist dabei im TM2-Kontext in der Signatur nicht explizit 
erwahnt, da es als Blackboard hinter der API gekapselt ist, vgl. Abschnitte 1.1.3 S. [3] und 2.3.3 
S.fT6|: 



process ( input : Li st [ Annot at ion [ I ] ] ) : Li st [ Annot at ion [0] ] 



Besonders deutlich wird die konzeptuelle Ahnlichkeit zu Formel [T] im Zusammenhang mit Syn- 
thesen, die aus Daten und Informationen ein Modell bilden (vgl. Abschnitt 2.3.2, S. 14), und so wie 



in Formel[T]aus vorhandenen Informationen neue Informationen synthetisieren. Die Unterscheidung 
von Daten und Informationen ist hier rein metaphorisch (denn sowohl Daten als auch Informa- 
tionen werden als Annotationen reprasentiert) und entspricht so dem in Formel [l] ausgedriickten 
Kontinuum zwischen Daten und Informationen: 



bui Id (data: List [ Annot at i on [D] ] , info: List[ Annot at ion [I]]): Model [D , I] 



Annotationen zur Verortung von Daten in einem Merkmalsraum Das Konzept der Annota- 
tion kann als Verortung von Daten in einem n-dimensionalen Merkmalsraum betrachtet werden. 
Die n Typen der Annotationen stellen dabei die konzeptuellen Achsen des Raums dar, in dem 
die annotierten Daten beschrieben werden (z.B. Wortart, Bedeutung, oder Typographic). So kann 
etwa die Wortform Biggin in einem zweidimensionalen Merkmalsraum aus Interpretation (mit den 
Werten 'Personenname' und 'Ortsname') und Visualisierung (mit den Werten 'fett' oder 'kursiv') 
an vier Stellen verortet werden: als fett gedruckter Personenname, als kursiv gedruckter Perso- 
nenname, als fett gedruckter Ortsname und als kursiv gedruckter Ortsname (Thaller 2009a:231). 
Distanzen zwischen unterschiedlichen, in diesem Raum gemessenen Positionen konnen dann mit 
unterschiedlichen, allgemeinen raumbezogenen Metriken gemessen werden (Thaller 2009a:235). 

In dieser Terminologie sind die TM2-Annotationen auf ihre konzeptuelle Achse im Merkmals- 
raum typisiert, und Agenten erweitern die Dimensionalitat dieses Raumes, z.B.: 

||tokenizer: Agent [String , Token] 

Ein solcher Agent etwa kann aus einer bestehenden Verortung von Daten in einem 1-dimension- 
alen Raum mit der Achse 'String' eine zusatzliche Verortung auf der konzeptuellen Achse 'Token' 
vornehmen. So konnen Agenten schrittweise, entsprechend dem beschriebenen Kontinuum zwischen 
idealtypischen Daten und idealtypischer Information, Daten zu Information verarbeiten, z.B. in 
einem nachsten Schritt, aufbauend auf die Token: 

|| gazetteer: Agent [Token , Sense] 

Basierend auf dieser Darstellung wird deutlich, dass die in dieser Arbeit beschriebene softwa- 
retechnische Losung fur typsicheres Text-Mining dem sehr allgemeinen Informationsmodell aus 
Thaller (2009a:237) entspricht: beliebige Informationsobjekte lassen sich als Anordnungen von m- 
dimensionalen Objekten T (Token) mit ihren (durch Annotationen definierten) Positionen in einem 
n-dimensionalen Merkmalsraum C (Context) beschreiben: 

<I >::={T m ,C n } (2) 

Im Text-Mining sind die Token dabei eindimensional und die Verortung im n-dimensionalen Kon- 
text ist durch die Annotationen gegeben, deren n Typen die Achsen des Merkmalsraums bilden. 
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Das beschriebene Informationsmodell bildet damit ein formales Modell, das in so unterschiedlichen 
Bereichen wie Text-Mining und Datenarchivierung softwaretechnisch umgesetzt werden kann, und 
in dessen Zentrum eine iterative Bildung von Information aus Daten, sowie die variable Dimensio- 
nalitat von Datenobjekten und Merkmalsraum steht. 

4.3. Fazit 

Auf Basis der Konzeption von annotationsbasierten Agenten in Kapitel [T] wurden in Kapitel [2] 
Werkzeuge und eine formale Notation zur Beschreibung und Durchfiihrung von Experimenten 
im Text-Mining entwickelt, in Form einer statisch typisierten, eingebetteten DSL. Am Beispiel 
von maschinellem Lernen zur Klassifikation wurden in Kapitel [3] die Vorteile und Moglichkeiten 
der Kombination von Werkzeugen und DSL dargestellt, bei der auf einfache Weise komplexe Ex- 
perimentserien durchgefuhrt und automatisch dokumentiert werden konnen. In Kapitel [4] wurde 
zusammenfassend dargestellt, wie das konsequent genutzte Konzept der generischen, typsicheren 
Annotation dabei zur Modellierung von Prozessen der Informationsverarbeitung genutzt werden 
kann, und inwiefern es einem allgemeinen Informationsmodell entspricht, das iiber die Textprozes- 
sierung hinausgeht. Als generischer Formalismus zur Annotation bildet so die typsichere Model- 
lierung ein zentrales Element nicht nur des Text-Mining, sondern einer allgemeinen Disziplin der 
Informationsverarbeitung. 
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A. Implementierungsdetails 



A.l. Projektstruktur und Komponenten 

Die Implementierung der in dieser Arbeit beschriebenen Software ist online verfiigbar 64 . Die Soft- 
ware umfasst drei Projekte: tm2.core (Framework und Java-API), tm2. agents (Implementierung 
von Agenten in Java) und tm2.scala (Scala-DSL und Implementierung von Agenten in Scala). 
Abbildung 16 beschreibt die Abhangigkeiten der drei Projekte. 



tm2.core 



tm2 .agents 



benotigt 



tm2. scala 



Abbildung 16: Projektabhangigkeiten 



Fur eine Reproduktion der beschriebenen Ergebnisse ist ein plattformunabhangiger, automati- 
sierbarer Erstellungs- und Testprozess von zentraler Bedeutung (vgl. Clark 2006). Die beschriebene 
Software kann daher in einem Schritt mithilfe von Ant 65 gebaut werden. Da das tm2.scala-Projekt 



von den anderen abhangt (vgl. Abb. 16, S. 53), enthalt dieses das zentrale Ant-Skript, das durch 
Ausfiihren von ant im Verzeichnis tm2.scaia/ ausgefiihrt werden kann. Das zentrale Ant-Skript ruft 
die Build-Skripte der anderen Projekte auf, erzeugt Jar-Archive, fiihrt die Tests aus und generiert 
Dokumentation zu API und Testergebnissen. 

A. 2. Implementierung der Werkzeuge 
A.2.1. API 

In den folgenden Abschnitten finden sich die zentralen Interfaces zur typsicheren Modellierung von 
Text-Mining-Experimenten mithilfe der Java-API von TM2. 

A.2.2. Agent 

/* * 

* Interface for an agent. This is a Strategy Interface (cf. Bloch 2008, Item 21). 

* ©param <I> The type of the input annotations , must be comparable and serializable 



64 TM2: typesafe modeling in text mining, http://github.com/fsteeg/tm2 

65 Apache Ant, http://axit.apache.org/ 
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* Sparam <0> the type of the output annotations, must be comparable and serializable 
*/ 

public interface Agent<I extends Comparable <I > & Serializable, Q extends Comparable <0 > & 
Serializable > { 

List < Annot at ion <D > > pr oces s ( List < Annot at ion <I > > input); 

} 

A. 2. 3. Annotation 

/* * 

* The interchange format of a text mining application: an annotation of data with meta-data. 

* Sparam <T> The type of the annotation 
*/ 

public interface Annot at ion <T> extends Comparable < Annotation <T>> , Serializable { 
Class <? extends Agent <? , ?>> author () ; 
URL ge tDat aLo cat i on ( ) ; 
T getValue () ; 
Biglnteger getStartO; 
Biglnteger getEndO; 

} 

A. 2. 4. Analysis 

/* * 

* A simple linear interaction of agent s exchanging typed annotations. 

* Qparam <T> The annotation type exchanged in this analysis 

*/ 

public interface Analysis <T extends Comparable <T> & Serializable > { 
List <Agent <? , T>> sourcesQ; 
List <Agent <T , ?>> targetsQ; 

Map<Class<? extends Agent <? , ?>>, List < Annot at ion <?>> > run ( 

final Map<Class<? extends Agent <? , ?>>, Li st < Annot at ion <? > > > blackboard); 

} 

A. 2. 5. Synthesis 

/* * 

* Synthesis of data and info into a model . 

* Sparam <D> The data type 

* Sparam <I> The info type 
*/ 

public interface Synthesis <D extends Comparable <D> & Serializable, I extends Comparable < I > & 
Serializable > { 

Map<Class<? extends Agent <? , ?>>, List < Annot at ion <?>> > run ( 

Map<Class<? extends Agent<?, ?>>, Li st < Annot at ion <? > > > blackboard); 
List <Agent <? , D>> data(); 
List <Agent <? , I>> info(); 
Model <D , I> model () ; 

} 

A.2.6. Model 

/* * 

* A model for mapping data of type D to info of type I. 

* Sparam <D> The data type 

* Sparam <I> The info type 
*/ 

public interface Model<D extends Comparable <D> & Serializable, I extends Comparable <I > & 
Serializable > { 

Model<D, I> train (List < Annotation <D>> data, List < Annot at ion < I >> info); 

} 
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A. 2. 7. Eigenstandige DSL 

Xtext-Grammatik Grammatik der eigenstandigen Xtext-DSL (vgl. Abschnitt 2.4.1, S. 22): 



/* Xtext experiment grammar */ 
Experiment : 

"Experiment" name = STRING "Data" corpus =STRING "Out" output = STRING 

"Import" ( imports+=STRING) + 

(interactions+=Interaction)+ 

("Evaluate" ( eval Agent s += ID ) + "Against" evalLocat ion= STRING )? ; 
Interaction : sour ce =Sour ce "->" type=ID "->" target =Target 
Source : ( sourceAgents += Agent )+ ; 
Target : ( t ar get Agent s += Agent )+ ; 
Agent : name=ID; 



Textuelles Modell Beispiel fiir ein Experiment mit der eigenstandigen DSL (vgl. Abschnitt 2.4.1 



S. 22): 



/* Xtext experiment */ 

Experiment "NE" Data " data/Corpus . txt " Out " output / Result " 
Import " com . quui . amas . agent s " " com . quui . amas . types " 

Corpus -> String -> Tokenizer . // Read: Corpus via String to Tokenizer 

Tokenizer -> String -> Gazetteer Counter. 

Evaluate Gazetteer Against " data/Gold_Gazetteer . xml " 



Xpand-Template: Java-Generierung Xpand- Template, generiert Code zur Nutzung der TM2- 



Java-API (s. Abschnitt 2.3, S. 12) aus der eigenstandigen DSL (s. Abschnitt 2.4.1, S. 22). Elemente 
zwischen « und » sind Xpand-Kontrollstrukturen zur Steuerung der Generierung: 

<<REM>> The generator template for the "TM2-DSL to Java Compiler" <<ENDREM>> <<IMP0RT tm2>> 
<<DEFINE main FOR Experiment >> <<FILE name + " . j ava " >> 

import java.util.*; import com . quui . tm2 .* ; import com.quui.tm2.doc.*; import com . quui . tm2 . ut i 1 .* ; 

<<F0REACH imports AS i>> import <<i>>.*; <<ENDFOREACH >> 

/** Generated TM2 experiment. */ 

public class <<name>> implements Runnable { 

public static void main ( String [] args) { new <<name > > ( ) . run ( ) ; } 
public void run () { 

/* Instantiate an experiment: */ 
String output = " <<output >> " ; 

Experiment x = Experiments . create (" <<name >>" , " <<corpus >> " , output); 
List <Analysis <?>> interactions = new Arr ayLi st <Analys i s <?>>() ; 

/* Define the interaction of agents in the experiment: */ <<F0REACH interactions AS i>> 
/* <<i . source . sourceAgents . name >> via <<i.type>> to <<i . target . targetAgents . name >> : */ 
Analysis <<<i . type >>> int er act i on < < int er ac t i ons . indexOf ( i ) >> = Analy s i s . cr eat e ( ) ; 

<<F0REACH i . source . sourceAgents AS s>> 
interaction<<interactions . indexOf (i) >> = 

interaction<<interactions.indexOf(i)>>.withSource(new <<s. name >>()) ;<<ENDFOREACH>> 

<<F0REACH i . target . targetAgents AS t>> 
interaction<<interactions . indexOf (i)>> = 

interaction << interact ions . indexOf ( i) >> . withTarget (new <<t . name >> () ) ; <<ENDFOREACH >> 
interactions . add (interaction<<interactions.indexOf(i)>>);<<ENDFOREACH>> 
/* Run the experiment with all the interactions: */ 
for (Analysis<?> i : interactions) { x . addlnt er ac t ion ( i ) ; } 
x . run ( ) ; 

/* Evaluate against a gold standard: */ 

Evaluation evaluation = new Evaluation ( output + " . xml " ) ; < < FOREACH evalAgents AS e>> 
evaluation . evaluate ("<< evalLocat ion >> " , <<e>> . class ) ; < < ENDFOREACH > > 
/* Export both annotations and documentation */ 
Document ation.of(experiment) ; 

} 

} 

<<ENDFILE >> 
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|| <<ENDDEFINE >> 



Generierter Code: Java Generierter Java-Code zur Nutzung der TM2-API, auf Basis des in der 



Xtext-DSL geschriebenen Experiments (s.o.) durch das Xpand- Template (s.o.), vgl. Abschnitt 2.3 

S.H2 ' 

import java.util.*; import com . quui . tm2 . * ; import com.quui.tm2.doc.*; import com . quui . tm2 . util . * ; 
import com . quui . tm2 . agents . * ; import com . quui . tm2 . types . * ; 
/** Generated TM2 experiment. */ 
public class NE implements Runnable { 

public static void main ( String [] args) { new NE () . run () ; } 
public void run() { 

/* Instantiate an experiment: */ 
String output = " output / Result " ; 

Experiment x = Experiments . create ("IE" , " data/ Corpus . txt " , output); 
List <Analysis <?>> interactions = new Arr ayList <Analys i s <?>>() ; 
/* Define the interaction of agents in the experiment: */ 
/* [Corpus] via String to [Tokenizer] : */ 
Analysis <String > interactionO = Analy s e s . create () ; 
interactionO = interactionO . withSource (new Corpus ()) ; 
interactionO = interactionO . withTarget (new Tokenizer () ; 
interactions . add (interactionO) ; 

/* [Tokenizer] via String to [Gazetteer, Counter]: */ 
Analysis <String > interactionl = Analy s e s . cr eat e () ; 
interactionl = interactionl . withSource (new Tokenizer ()) ; 
interactionl = interactionl . withTarget (new Gazet t e er ( ) ) ; 
interactionl = interactionl . withTarget (new Counter () ) ; 
interactions . add (interactionl) ; 

/* Run the experiment with all the interactions: */ 
for (Analysis<?> i : interactions) { x = x.with(i); } 
x . run ( ) ; 

/* Evaluate against a gold standard : */ 

Evaluation evaluation = new Evaluation ( output + ".xml"); 
evaluation. evalu at e("data/Gold_Gazetteer. xml", Gazetteer. class); 
evaluation. evaluate ("data/Gold_Gazetteer . xml", Count er . class) ; 
/* Export both annotations and documentation */ 
Document ation.of(experiment); 

} 

} 



A.2.8. Eingebettete DSL 

Die eingebettete Scala-DSL umfasst 4 Scala-Entitaten, welche die Funktionalitat der Java-API an- 
reichern: RichAgent, RichAnalysis, RichSynthesis und RichExperiment. Fur diese Entitaten exis- 
tiert jeweils eine Klasse und ein Singleton-Objekt (vgl. Odersky et al. 2008:59). 

A. 2. 9. RichAgent 

Class Klasse: rich wrapper fiir Agent . 

/**A rich agent that supports the Scala DSL syntax:*/ 

abstract class RichAgent [I< : Comparable [I] with Ser ial izable , < : Compar abl e [0] with Ser i al izable ] 
extends Agent[I,0]{ 
val backingAgent : Agent [1,0] 

// . . . 

} 
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Object Singleton-Objekt: rich wrapper fur Agent. 



object RichAgent{ 

/** Implicit conversion from Java agents to rich Scala agents: */ 

implicit def agentWrapper [I< : Comparable [I] with Serializable , <: Comparable [0] with 
Serial izable] 
(agent : Agent [1,0]) = { /*...*/ } 
// . . . 



A. 2. 10. RichAnalysis 

Class Klasse: rich wrapper fur Analysis. 

/**A rich analysis that supports the Scala DSL syntax:*/ 
abstract class Ri chAnalys i s [T <: Comparable [T] with Serializable] 
extends Analysis [T]{ 
val backinglnt er act i on : Analysis [T] 

def I (next: Analysis [_]) : Ri chExper iment = { /*...*/ } 

def I [V< : Comparable [V] with Serializable, C <: Comparable [C] with Serializable] (next: 
Synthesis [V , C] ) : RichExperiment = { /*...*/ } 

} 



Object Singleton-Objekt: rich wrapper fur Analysis. 

object Ri chAnalys i s { 

/** Implicit conversion from Java analyses to rich Scala analyses: */ 

implicit def analy s i sWr apper [T< : Comparable [T] with Serializable] (interaction : Analysis 
new RichAnalysis [T] { /*...*/ } 

// ... 



A. 2. 11. RichSynthesis 

Class Klasse: rich wrapper fur Synthesis. 

/**A rich synthesis that supports the Scala DSL syntax:*/ 

abstract class Ri chSynthes i s [V <: Comparable [V] with Serializable, C <: Comparable [C] with 
Serializable] 
extends Synthesis [V , C] { 
val backingTr aining : Synthesis [V , C] 

def I (next: Analysis [_]) : RichExperiment = { /*...*/ } 

} 



Object Singleton-Objekt: rich wrapper fur Synthesis. 



object Ri chSynthe s i s { 

/** Implicit conversion from Java syntheses to rich Scala syntheses: */ 

implicit def synthe s i sWr apper [V <: Comparable [V] with Serializable, C <: Comparable [C] with 
Serial izable] 
(training : Synt hes i s [V , C] ) = 

new RichSynthesis [V , C] { /*...*/ } II... 

} 



A. 2. 12. RichExperiment 

Class Klasse: rich wrapper fur Experiment. 
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/**Wrapper class for Experiment . Builder , builds on-the -fly in the run and eval methods.*/ 
class Ri chExper iment ( x : Experiment . Builder ) { 
// . . . 

/** Run and export an experiment. */ 
def run: Ri chExper iment = { 
experiment . run ; this 

> 

def ! : RichExperiment = { val r = run; documentation = WikitextExport . of ( experiment ) ; r } 
def | (next: Analysis [_]) : RichExperiment = { x . analysis (next ) ; new RichExperiment (x) } 
def I [V <: Comparable [V] with Serializable , C <: Comparable [C] with Ser i al izable ] ( next : 
RichSynthesis [V , C]): RichExperiment = { 
x . synthesis (next ) ; new RichExperiment (x) 

} 

} 



Object Singleton-Objekt: rich wrapper fur Experiment! 

object RichExperiment { 

def apply ( interactions : Analy s i s [_]*)( synthese s : Synthesis[_, _]*): Ri chExper iment = { /*...*/ } 
// Implicit conversion from tuples of agents to rich analysis and synthesis wrappers 
implicit def expsToExper iment s ( exps : List [RichExperiment ]) : List [Experiment] = 
exps . map (_ . experiment ) 

// ALLOWS: al : Agent [_, D] -> a2 : Agent [D , _] : RichAnalysis [D] 
implicit def agent Tupl eTo Analy s i s [D <: Comparable [D] with Serializable] 
(tuple: (Agent[_, D] , Agent [D , _])): Ri chAnaly s i s [D] = { /*...*/ } 

// ALLOWS: al : Agent [_, D] -> ( a2 : Agent [D , 0] , a3 : Agent [D , ] ) : RichAnalysis [D] 
implicit def agentTupleTupleToAgentList [I <: Comparable [I] with Serializable, D <: 
Comparable [D] with Serializable, <: Comparable [0] with Serializable] 
(tuple: (Agent [I, D] , (Agent[D, 0], Agent [D , 0]))): Ri chAnaly s i s [D] = 
listOf Agent sTo Agent List ( ( t up le._l, List (tuple . _2 . _1 , tuple. _2 . _2) ) ) 

// ALLOWS: al : Agent [_, D] -> List ( a2 : Agent [D , ] , a3 : Agent [D , 0] ) : Ri chAnaly s i s [D] 
implicit def 1 i s t Of Agent sTo Agent Li st [ I <: Comparable [I] with Serializable, D <: Comparable [D] 
with Serializable, <: Comparable [0] with Serializable] 

(tuple: (Agent [I, D] , List [Agent [D , 0]])): RichAnalysis [D] = 

agent Tupl eTo Agent Li st (( tuple . _1 , new AgentList[D, ]( tuple . _2 )) ) 

// ALLOWS: al : Agent [_, D] -> a2 : Agent [D ,_ ] / a3 : Agent [D , _] : RichAnalysis [D] 

implicit def agentTupleToAgentList [01 <: Comparable [01] with Serializable, 02 <: Comparable [02] 
with Serializable] 

(tuple: (Agent[_, 01], AgentList [01 , 02])): Ri chAnaly s i s [0 1 ] = { /*...*/ } 

// ALLOWS: al : Agent [V , C] + a2 : Agent [V , C] -> m:Model[V,C] : Ri chSynt hes i s [V , C] 
implicit def agent PairMode lTupleToSynthe s i s [V <: Comparable [V] with Serializable, C <: 
Comparable [C] with Serializable] 

(tuple: ((Agent [_, V], Agent [_ , C] ) , Model[V, C] ) ) : Ri chSynthes i s [ V , C] = { /*...*/ } 

} 

A.2.13. XML-Export 

XML-Schema-Definition (XSD) des XML-Exportformats fur Experimente unci Annotationen in 
TM2: 

<?xml version = " 1 . " encoding = " UTF -8 " ? > 

<xsd:schema targetNamespace = "http: //www . quui . com/ tm2 " e lement FormDef ault = " qual if ied " 
xmlns:xsd="http: //www .w3.org/2001/XMLSchema" xmlns:tm2="http:// www . quui . com/ tm2 " > 
<xsd:complexType name=" experiment "> 
<xsd : sequence > 

<xsd:element name="agent" type =" tm2 : agent " maxO c cur s =" unbounded " minO c cur s = " 1 " > 
</xsd : element > </ xsd : sequence > 

<xsd : attribute name="data" type =" xsd : string " use =" required "></ xsd : at tribut e > 
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</xsd: complexType> 
<xsd : complexType name =" agent " > 
<xsd: sequence > 

<xsd : element name="a" type="tm2:a" maxO ccurs =" unbounded " minOc cur s = " 1 " > 
</ xsd : element > 
</xsd: sequence> 

<xsd : attribute name="name" type =" xsd : string " use =" required "></ xsd : at tribute > 

</xsd: complexType> 

<xsd : complexType name="a"> 

<xsd : attribute name="start" type =" xsd : string " use =" required "></ xsd : at tribute > 
<xsd : attribute name="end" type =" xsd : str ing " use =" required "></ xsd : at tribut e > 
<xsd : attribute name = "label" type = " xsd : str ing " use = " required "></ xsd : at tribut e > 
<xsd : attribute name = " ob j ect " t ype = " xsd : st r ing " use = " opt i onal " ></ xsd : at t r ibut e > 

</xsd: complexType > 

<xsd:element name = " experiment" type = " tm2 : experiment "x/xsd: element > 
</ xsd : schema> 



A. 2. 14. XCDL-Transformation 



Transformation von TM2-Annotationen zu XCDL mittels XSLT (vgl. Abschnitt 



<?xml version=" 1 . " encoding= " UTF -8 " ? > 

<isl : stylesheet version=" 1.0" xmlns:xsl="http: //www .w3 . org/1999/XSL/Transform"> 
<!-- Transform a TM2 experiment to a Planets XCDL --> 
<xs 1 : tempi at e mat ch=" experiment "> 

<xcdl xmlns:xsi = "http: //www . w3. org/2001/ XMLS enema-instance" 

xsi:schemaLocation="http: //www . planets -project . en/xcl/scheias/xcl 
. ./schemas/xcdl/XCDLCore.xsd" xmlns="http: //www . planets -project . en/ xcl/schemas/xcl" 
id=" 0"> 

<object id="ol"> 

<normData type="text" id="ndl"> <xsl : value -of sele ct = " @dat a " /> </normData> 
<property id="pl" source="raw" cat="descr"> 

<name id="id58">textualAnnotation</name> 

<xsl : apply -templates mode = " valueSet s " /> 
</ property > 

<xsl : apply -templates mode =" proper ty Set s " /> 
</ obj ect > 
</xcdl > 
</xsl:template> 

<!-- Transform a TM2 annotation label to an XCDL value set --> 
<xsl : template match="a" mode =" valueSet s " > 

<valueSet id="i_il_i36_il_i{position()}"> 

<labValue> <val> <xsl : value -of sele ct =" @ label " /> </val> < type > str ing </ type > 
</labValue> 

<dataRef ind= " normSpe c if i c " property Set Id= " id_ { pos it i on ()} " /> 
</ valueSet > 
</xsl:template> 

<!-- Transform TM2 annotation positional information to an XCDL property set --> 
<xsl : template match="a" mode = " proper ty Set s " > 
<propertySet id="id_{position()}"> 

<valueSetRelations> <ref valueSetId="i_il_i36_il_i{position()}" 

name = " t ext ual Annot at i on " /> </ valueSet Re lat i ons > 
<dataRef> <ref begin= " {® start } " end="{@end}" id="ndl" /> </dataRef> 
</propertySet> 
</xsl : template > 
</xsl:stylesheet> 



4.2.1, S. 48): 
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A. 3. Implementierung der Experimente 
A. 3.1. Informationsextraktion 



Details zur Implementierung des in Abschnitt 3.1.2 , S. 30 beschriebenen einfuhrenden Experiments 
zur Informationsextraktion flnden sich im tm2.agents-Proiekt (vgl. Hinweise in Abschnitt A.l, S. 
53}. 



A.4. WSD 

A. 4.1. Text fiir Beispielexperiment mit Pseudoambiguitat 

Text mining, sometimes alternately referred to as text data mining, refers generally to the process 
of deriving high quality information from text. High quality information is typically derived through 
the dividing of patterns and trends through means such as statistical pattern learning. Text mining 
usually involves the process of structuring the input text (usually parsing, along with the addition 
of some derived linguistic features and the removal of others, and subsequent insertion into a data- 
base), deriving patterns within the structured data, and finally evaluation and interpretation of the 
output. 'High quality' in text mining usually refers to some combination of relevance, novelty, and 
interestingness. Typical text mining tasks include text categorization, text clustering, concept/entity 
extraction, production of granular taxonomies, sentiment analysis, document summarization, and 
entity relation modeling (i.e., learning relations between named entities). 66 



A. 4. 2. Implementierung der Agenten 

Im Folgenden finden sich Details zu den Agenten-Implementierungen fiir die WSD-Experimente 
in Abschnitt 3.3, S. 35, z.T. gekiirzt (der komplette Code findet sich in den Projekten tm2. agents 
und tm2.scala, s. WsdUsageSenseval.scala als Einstiegspunkt, vgl. Hinweise in Abschnitt A.l S. 
531: 



SensevalData Agent fiir Zugriff auf Kontexte der Daten (in Scala, Agent [String, Context]); 

abstract class SensevalData ( s : String) extends Agent [String , Context] { 
val file = new File(s) 

val trainDataReader = new STAXSensevalDataReader ( f ile ) ; 

val samples: List [Ambiguity] = t r ainDat aReader . get Ambigui t i es . t oLi st 

val words: j ava . ut il . Li st [ Str ing] = trainDataReader . getWords 

def process ( input : j ava . ut i 1 . Li st [ Annot at ion [ St r ing ] ] ) = samples . map ( asAnnotation (_) ) 
def asAnnotation ( amb : Ambiguity): Anno [ Cont ext ] = { 
Annotations . create [Context] ( 

classOf [SensevalData] , amb . getContext : Context , amb . getContext . targetStart : Int , 
amb . getContext . target End : Int) 

} 

override def toString = f ile . t oURL . t oSt ring 



SensevalSense Agent fiir Zugriff auf Zielworte der Daten (in Scala, Agent [Context , Ambiguity]); 

class SensevalSense ( s : String) extends Agent [Context , Ambiguity] { 
val words: List [String] = Nil 



66 Einc Definition des Text- Mining von http://en.wikipedia.org/wiki/Text_mining 
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val trainDataReader = new STAXSensevalDataReader (new File(s)); 
val samples: List [Ambiguity] = t r ainDat aReader . get Ambigui t i es . t oLi st 
def process ( input : j ava . ut i 1 . Li st [ Annot at ion [ Context ]] ) = samples . map ( sens e (_) ) 
def sense (amb: Ambiguity): Anno [Ambiguity ] = { 
Annotations . create [Ambiguity] ( 

classOf [SensevalData] , amb : Ambiguity , amb . getContext . targetStart : Int , 
amb . getContext . target End : Int) 

} 

override def toString = " Sens e valSens e ( " + s+ " ) " 



ContextFeatures Agent fur die Merkmalsberechnung (in Java, Agent <Cont ext , FeatureVector> ) '. 

public abstract class ContextFeatures implements Agent < Cont ext , FeatureVector > { 
/* . . . */ 

public List < Annotation <FeatureVector >> proces s ( List < Annot at i on < Cont ext >> input) { 

Li st < Annot at ion < Feature Vect or > > result = new Ar rayList < Annot at ion < Feature Ve ct or >>() ; 
for (int i = 0; i < input . s ize () ; i++) { 
Context c = input . get ( i ). get Value () ; 

FeatureVector vector = new Featur eVe ct or ( gener at or . get Feat ures ( c . target , c.all, context * 
2) , c . lemma , c . id) ; 

Annotation <FeatureVector > annotation = Annot at i ons . create ( get Clas s () , vector, 

input .get(i) .getStartO , input . get ( i ) .getEndO) ; 
result . add ( annot at i on ) ; 

} 

return result ; 
} 

/*...*/ 



SensevalClassifier Agent fur die numerische Klassifikation (in Java, Agent<FeatureVector , Sense>): 

public class SensevalClassifier implements Agent <FeatureVector , Sense>, Model <FeatureVector , 
Ambiguity > { 
/* . . . */ 

public Model <FeatureVector , Ambiguity> tr ain ( List < Annot at ion < Featur eVe ct or > > value, 
Li st < Annot at ion < Ambiguity > > correct) { 
/* . . . */ 

} 

public List < Annotation <Sense >> pr oc e s s ( List < Annot at ion < Featur eVe ct or > > input) { 
List < Annotation <Sense >> result = new Arr ayLi st < Annot at ion < Sense >>() ; 
for ( Annot at ion < Featur e Vect or > annotation : input) { 
FeatureVector f eat ur e Vec t or = annot at ion . get Value () ; 
WsdCl as s if ier classifier = lexi con . get ( f eatur e Ve ct or . 1 emma ) ; 
String correct = clas s if ier . clas s if y ( f eatur e Vec t or . get Value s ()) ; 
Sense r = new Sense ( f eatur e Vec t or . id , featureVector . lemma , correct); 
result . add( Annot at ions . create (SensevalClassifier . class , r, annot at ion. getStartO, 
annot at ion. get End())) ; 

} 

return result ; 

} 

/*...*/ 



SensevalEval Agent fur Zugriff auf nativen Senseval-Scorer (in Scala, Agent [sense, string]): 

class SensevalEval (s : String) extends Agent [Sense , String] with Evaluation { 

// . . . 

def getResultString = getF . toString 

def process ( input : j ava . ut i 1 . Set [Annot at ion [ Sense ]] ) = { 

val sensevalOutput = for (anno <- input; sense = anno . get Value ) yield sense . lemma + " " + 
sense . id + " " + sense . correct 
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val res = sensevalOutput . sorted . mkString (" \n" ) 
val file = new File (" f ile s / sense val . re suit " ) 
val fw = new Fi leWr it er ( f i le ) 
f w . write (res ) ; fw. close () 
result = f ile . get Canoni calPath 

val process = Runt ime . getRunt ime ( ) . exec ( " f iles / s cor er 2 f ile s / sense val . result 

f iles / Engl i shLS . t e st . key f ile s / Engl i shLS . s ensemap -g" + (if ( grain== " f ine " ) "" else 
grain) ) 

print ln(Source.fromInputStre am (process. getErrorStre am) .getLines.mkString("\n")) 
response = Source. fromlnputStre am (process. getlnputStre am) .getLines.mkString("\n") 
Nil 

} 

def getF: Float = { 

val r = """precision: ( [" ]+) '.r 

val Some (res) = r findFirstln response 
val r(p) = res 
p . toFloat 

} 

} 



A. 4. 3. Vollstandige Ergebnisse 

Die folgende Seite enthalt die vollstandige aus der generierten HTML-Dokumentation mithilfe des 



Programms html2latex 67 konvertierte Ergebnistabelle fur die Experimente in Abschnitt 3.4, S. 39 



(im HTML- Format enthalt die Spalte Details Hyperlinks zu den Detailseiten eines Experiments). 



67 HTML to LaTeX, http://htmltolatex.sourceforge.net/ 
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